Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: feature
This patch updateds cryptodev engine uses new DPDK Cryptodev
API planned to be upstreamed in DPDK 20.11.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Signed-off-by: Piotr Bronowski <piotrX.bronowski@intel.com>
Change-Id: I8dd1a8ac643f1e952deb787e466b76ea7aa5f420
|
|
Type: feature
This adds api calls for the following CLIs:
* set sw_scheuduler worker <N> crypto on|off
* set crypto async dispatch polling|interrupt
* set crypto handler
* set crypto async handler
Change-Id: Ic701d149c440e42ea4575da42b9f69e4c8759602
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
|
|
Type: feature
This patch adds new sw_scheduler async crypto engine.
The engine transforms async frames info sync crypto ops and
delegates them to active sync engines. With the patch it
is possible to increase the single worker crypto throughput
by offloading the crypto workload to multiple workers.
By default all workers in the system will attend the crypto
workload processing. However a worker's available cycles
are limited. To avail more cycles to one worker to process
other workload (e.g. the worker core that handles the RX/TX
and IPSec stack processing), a useful cli command is added
to remove itself (or add it back later) from the heavy
crypto workload but only let other workers to process the
crypto. The command is:
- set sw_scheduler worker <idx> crypto <on|off>
It also adds new interrupt mode to async crypto dispatch node.
This mode signals the node when new frames are enqueued
as opposed to polling mode that continuously calls dispatch node.
New cli commands:
- set crypto async dispatch [polling|interrupt]
- show crypto async status (displays mode and nodes' states)
Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com>
Signed-off-by: DariuszX Kazimierski <dariuszx.kazimierski@intel.com>
Reviewed-by: Fan Zhang <roy.fan.zhang@intel.com>
Change-Id: I332655f347bb9e3bc9c64166e86e393e911bdb39
|
|
Type: feature
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
Signed-off-by: Dariusz Kazimierski <dariuszx.kazimierski@intel.com>
Signed-off-by: Piotr Kleski <piotrx.kleski@intel.com>
Change-Id: I4c3fcccf55c36842b7b48aed260fef2802b5c54b
|
|
Type: fix
Change-Id: I9e168a87aff1882636840eb94e5509cd08885fb5
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Type: feature
Change-Id: Ie072a7c2bbb1e4a77f7001754f01897efd30fc53
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Do not overflow ops_handlers vector.
Type: fix
Change-Id: I8d5e7fb8125a7bd87ecfe6f4f1390fb9f43dad8f
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
opt_data is defined as a array, while in some code, e.g., function
vnet_crypto_get_op_type, it's used as vec.
vec api is not applicable to static arraies.
src/vnet/crypto/crypto.h:234:70: error: address of array 'cm->opt_data' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
vnet_crypto_op_data_t *od = ({ do { if ((0 > 0) && ! ((id) < ((cm->opt_data) ? (((vec_header_t *) (cm->opt_data) - 1)->len) : 0)))
Type: fix
Change-Id: I0b6754406e4216ca975bc1da4b5d4ce293a9bb45
Signed-off-by: Lijian Zhang <Lijian.Zhang@arm.com>
|
|
requested alogrithm.
Type: feature
Change-Id: I19a9c14b2bb52ba2fc66246845b7ada73d5095d1
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
there's no use case to just change the key of an SA. instead the SA
should be renegociated and the new SA applied to the existing SPD entry
or tunnel.
the set_key functions were untested.
Type: refactor
Change-Id: Ib096eebaafb20be7b5501ece5a24aea038373002
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I45618347e37440263270baf07b2f82f653f754a5
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Crypto algorithms have different requirements on key length. As we do
not support key stretching (eg. PBKDF2), user must provide the exact
key length used by the algorithm.
Failing that means low-level crypto functions might read garbage (eg.
aes128_key_expand() will read 16-bytes, regardless of the key provided
by the user).
Change-Id: I347a1ea7a59720a1ed07ceaad8b00a31f78458c9
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
hard code IV and key lengths based on cipher.
Init IV from random data, use AES instruction to rotate.
Change-Id: I13a6507d12267b823c528660a903787baeba47a0
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Iff6f81a49b9cff5522fbb4914d47472423eac5db
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I9db1b74097c9df587b9265b14a969d347bcb731a
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I438ef1f50d83560ecc608f898cfc61d7f51e1724
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I40124f8d6e529256b1ccc6eb78dda9c5119b8951
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Change-Id: Ibf320b3e7b054b686f3af9a55afd5d5bda9b1048
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|