summaryrefslogtreecommitdiffstats
path: root/src/plugins/crypto_ia32
AgeCommit message (Collapse)AuthorFilesLines
2019-06-13crypto-ia32: fix typo in ifdef for avx512 versionNeale Ranns1-1/+1
Type: Fix Fixes: dd2423ef Change-Id: I76f0ed5027161c396186845043f5afe395c20280 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-06-03crypto_ia32: native AES-GCM implementationDamjan Marion5-1/+1046
Change-Id: I006a150577e897731649f21908b4789e2eb485c3 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-05-31crypo_ia32: don't optimize debug buildsDamjan Marion2-1/+5
Type: fix Fixes: d5023a72 Change-Id: I17cf7887d1274cf3ca9301ec87b8c8f539359456 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-05-23crypto_ia32: multiarchDamjan Marion5-58/+70
Change-Id: Iead43a2b524b735a2069e611d899cd41d3a8efdc Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-05-16init / exit function orderingDave Barach1-5/+7
The vlib init function subsystem now supports a mix of procedural and formally-specified ordering constraints. We should eliminate procedural knowledge wherever possible. The following schemes are *roughly* equivalent: static clib_error_t *init_runs_first (vlib_main_t *vm) { clib_error_t *error; ... do some stuff... if ((error = vlib_call_init_function (init_runs_next))) return error; ... } VLIB_INIT_FUNCTION (init_runs_first); and static clib_error_t *init_runs_first (vlib_main_t *vm) { ... do some stuff... } VLIB_INIT_FUNCTION (init_runs_first) = { .runs_before = VLIB_INITS("init_runs_next"), }; The first form will [most likely] call "init_runs_next" on the spot. The second form means that "init_runs_first" runs before "init_runs_next," possibly much earlier in the sequence. Please DO NOT construct sets of init functions where A before B actually means A *right before* B. It's not necessary - simply combine A and B - and it leads to hugely annoying debugging exercises when trying to switch from ad-hoc procedural ordering constraints to formal ordering constraints. Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c Signed-off-by: Dave Barach <dave@barachs.net>
2019-05-03plugins: clean up plugin descriptionsDave Wallace1-1/+1
- Make plugin descriptions more consistent so the output of "show plugin" can be used in the wiki. Change-Id: I4c6feb11e7dcc5a4cf0848eed37f1d3b035c7dda Signed-off-by: Dave Wallace <dwallacelf@gmail.com>
2019-04-25crypto_ia32: minor change logicallyZhiyong Yang1-2/+1
"break;" will never be run after "return;" Change-Id: I4fdfd10406fdf61897078746d28fa1ee32fb0081 Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
2019-04-25crypto: improve key handlingDamjan Marion4-14/+94
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-07crypto: coverity issuesDamjan Marion2-15/+27
Change-Id: I9db1b74097c9df587b9265b14a969d347bcb731a Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-04Add crypto_ia32 pluginDamjan Marion5-0/+632
Currently this plugin provies AES CBC optimized code. Encryption code supports parallel encryption of 4 buffers with different size and key which improves performance 4x compared to standard serialized aproach. On Skylake Server measured performance is around 0.71 clocks/byte with 256 buffers with size in range between 7000 and 8000 bytes. Measured performance includes overhead of processing crypto ops. Change-Id: I5ec2afee708fcdf16a4234926534dd64ff1155c3 Signed-off-by: Damjan Marion <damarion@cisco.com>