#
8a6fa6df |
|
24-Apr-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Keep only one bulk of full available DEKs One bulk with full available keys is left undestroyed, to service the possible requests from users quickly. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
12a9e1b7 |
|
24-Apr-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Add async garbage collector for DEK bulk After invalidation, the idle bulk with all DEKs available for use, is destroyed, to free keys and mem. To get better performance, the firmware destruction operation is done asynchronously. So idle bulks are enqueued in destroy_list first, then destroyed in system workqueue. This will improve performance, as the destruction doesn't need to hold pool's mutex. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
709f07fe |
|
15-Mar-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Reuse DEKs after executing SYNC_CRYPTO command To fast update encryption keys, those freed keys with need_sync bit 1 and in_use bit 0 in a bulk, can be recycled. The keys are cached internally by the NIC, so invalidating internal NIC caches by SYNC_CRYPTO command is required before reusing them. A threshold in driver is added to avoid invalidating for every update. Only when the number of DEKs, which need to be synced, is over this threshold, the sync process will start. Besides, it is done in system workqueue. After SYNC_CRYPTO command is executed successfully, the bitmaps of each bulk must be reset accordingly, so that the freed DEKs can be reused. From the analysis in previous patch, the number of reused DEKs can be calculated by hweight_long(need_sync XOR in_use), and the need_sync bits can be reset by simply copying from in_use bits. Two more list (avail_list and sync_list) are added for each pool. The avail_list is for a bulk when all bits in need_sync are reset after sync. If there is no avail deks, and all are be freed by users, the bulk is moved to sync_list, instead of being destroyed in previous patch, and waiting for the invalidation. While syncing, they are simply reset need_sync bits, and moved to avail_list. Besides, add a wait_for_free list for the to-be-free DEKs. It is to avoid this corner case: when thread A is done with SYNC_CRYPTO but just before starting to reset the bitmaps, thread B is alloc dek, and free it immediately. It's obvious that this DEK can't be reused this time, so put it to waiting list, and do free after bulk bitmaps reset is finished. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
c6e7d817 |
|
20-Jul-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Use bulk allocation for fast update encryption key We create a pool for each key type. For the pool, there is a struct to store the info for all DEK objects of one bulk allocation. As we use crypto->log_dek_obj_range, which is set to 12 in previous patch, for the log_obj_range of bulk allocation, 4096 DEKs are allocated in one time. To trace the state of all the keys in a bulk, two bitmaps are created. The need_sync bitmap is used to indicate the available state of the corresponding key. If the bit is 0, it can be used (available) as it either is newly created by FW, or SYNC_CRYPTO is executed and bit is reset after it is freed by upper layer user (this is the case to be handled in later patch). Otherwise, the key need to be synced. The in_use bitmap is used to indicate the key is being used, and reset when user free it. When ktls, ipsec or macsec need a key from a bulk, it get one with need_sync bit 0, then set both need_sync and in_used bit to 1. When user free a key, only in_use bit is reset to 0. So, for the combinations of (need_sync, in_use) of one DEK object, - (0,0) means the key is ready for use, - (1,1) means the key is currently being used by a user, - (1,0) means the key is freed, and waiting for being synced, - (0,1) is invalid state. There are two lists in each pool, partial_list and full_list, according to the number for available DEKs in a bulk. When user need a key, it get a bulk, either from partial list, or create new one from FW. Then the bulk is put in the different pool's lists according to the num of avail deks it has. If there is no avail deks, and all of them are be freed by users, for now, the bulk is destroyed. To speed up the bitmap search, a variable (avail_start) is added to indicate where to start to search need_sync bitmap for available key. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
4d570c71 |
|
19-Jul-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Add bulk allocation and modify_dek operation To support fast update of keys into hardware, we optimize firmware to achieve the maximum rate. The approach is to create DEK objects in bulk, and update each of them with modify command. This patch supports bulk allocation and modify_dek commands for new firmware. However, as log_obj_range is 0 for now, only one DEK obj is allocated each time, and then updated with user key by modify_dek. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
7a5b72c2 |
|
19-Jul-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Add support SYNC_CRYPTO command Add support for SYNC_CRYPTO command. For now, it is executed only when initializing DEK, but needed when reusing keys in later patch. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
204369e7 |
|
19-Jul-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Add new APIs for fast update encryption key New APIs are added to support fast update DEKs. As a pool is created for each key purpose (type), one pair of pool APIs to get/put pool. Anotehr pair of DEKs APIs is to get DEK object from pool and update it with user key, or free it back to the pool. As The bulk allocation and destruction will be supported in later patches, old implementation is used here. To support these APIs, pool and dek structs are defined first. Only small number of fields are stored in them. For example, key_purpose and refcnt in pool struct, DEK object id in dek struct. More fields will be added to these structs in later patches, for example, the different bulk lists for pool struct, the bulk pointer dek struct belongs to, and a list_entry for the list in a pool, which is used to save keys waiting for being freed while other thread is doing sync. Besides the creation and destruction interfaces, new one is also added to get obj id. Currently these APIs are planned to used by TLS only. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
94219254 |
|
27-Jul-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Refactor the encryption key creation Move the common code to general functions which can be used by fast update encryption key in later patches. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
55f0d6d2 |
|
07-Aug-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Add const to the key pointer of encryption key creation Change key pointer to const void *, as there is no need to change the key content. This is also to avoid modifying the key by mistake. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
fe298bdf |
|
22-May-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Prepare for fast crypto key update if hardware supports it Add CAP for crypto offload, do the simple initialization if hardware supports it. Currently set log_dek_obj_range to 12, so 4k DEKs will be created in one bulk allocation. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
60c8972d |
|
21-Nov-2022 |
Jianbo Liu <jianbol@nvidia.com> |
net/mlx5: Change key type to key purpose Change the naming of key type in DEK fields and macros, to be consistent with the device spec. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
c673b677 |
|
13-Mar-2022 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5: Header file for crypto Take crypto API out of the generic mlx5.h header into a dedicated header. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
c276aae8 |
|
26-Jan-2021 |
Roi Dayan <roid@nvidia.com> |
net/mlx5: Move mlx5e hw resources into a sub object This is to separate between resources attributes and other attributes we will want to use. Signed-off-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
2d64663c |
|
29-Jan-2020 |
Raed Salem <raeds@mellanox.com> |
net/mlx5: IPsec: Add HW crypto offload support This patch adds support for Connect-X IPsec crypto offload by implementing the IPsec acceleration layer needed routines, which delegates IPsec offloads to Connect-X routines. In Connect-X IPsec, a Security Association (SA) is added or deleted via allocating a HW context of an encryption/decryption key and a HW context of a matching SA (IPsec object). The Security Policy (SP) is added or deleted by creating matching Tx/Rx steering rules whith an action of encryption/decryption respectively, executed using the previously allocated SA HW context. When new xfrm state (SA) is added: - Use a separate crypto key HW context. - Create a separate IPsec context in HW to inlcude the SA properties: - aes-gcm salt. - ICV properties (ICV length, implicit IV). - on supported devices also update ESN. - associate the allocated crypto key with this IPsec context. Introduce a new compilation flag MLX5_IPSEC for it. Downstream patches will implement the Rx,Tx steering and will add the update esn. Signed-off-by: Raed Salem <raeds@mellanox.com> Signed-off-by: Huy Nguyen <huyn@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
|
#
bd673da6 |
|
02-Mar-2020 |
Saeed Mahameed <saeedm@mellanox.com> |
net/mlx5: Introduce TLS and IPSec objects enums Expose the TLS encryption key general object type enum correctly, and add the IPSec encryption key general object type enum. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
|
#
eed6f7dc |
|
15-Aug-2019 |
Saeed Mahameed <saeedm@mellanox.com> |
net/mlx5: Add missing include file to lib/crypto.c Add missing include file to avoid compiler warnings: drivers/net/ethernet/mellanox/mlx5/core//lib/crypto.c:6:5: warning: no previous prototype for ‘mlx5_create_encryption_key’ 6 | int mlx5_create_encryption_key(struct mlx5_core_dev *mdev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core//lib/crypto.c:60:6: warning: no previous prototype for ‘mlx5_destroy_encryption_key’ 60 | void mlx5_destroy_encryption_key(struct mlx5_core_dev *mdev, ... Fixes: 45d3b55dc665 ("net/mlx5: Add crypto library to support create/destroy encryption key") Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
|
#
55c9bd37 |
|
21-Jul-2019 |
Tariq Toukan <tariqt@mellanox.com> |
net/mlx5: crypto, Fix wrong offset in encryption key command Fix the 128b key offset in key encryption key creation command, per the HW specification. Fixes: 45d3b55dc665 ("net/mlx5: Add crypto library to support create/destroy encryption key") Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
|
#
45d3b55d |
|
05-Jul-2019 |
Tariq Toukan <tariqt@mellanox.com> |
net/mlx5: Add crypto library to support create/destroy encryption key Encryption key create / destroy is done via CREATE_GENERAL_OBJECT / DESTROY_GENERAL_OBJECT commands. To be used in downstream patches by TLS API wrappers, to configure the TIS context with the encryption key. Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|