RE: [EXTERNAL] [PATCH v2 1/2] crypto/mlx5: optimize AES-GCM IPsec operation

[Suanming Mou <suanmingm@nvidia.com>]

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Friday, June 14, 2024 2:49 PM
> To: Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
> <matan@nvidia.com>
> Cc: dev@dpdk.org
> Subject: RE: [EXTERNAL] [PATCH v2 1/2] crypto/mlx5: optimize AES-GCM IPsec
> operation
> 
> > To optimize AES-GCM IPsec operation within crypto/mlx5, the DPDK API
> > typically supplies AES_GCM AAD/Payload/Digest in separate locations,
> > potentially disrupting their contiguous layout. In cases where the
> > memory layout fails to meet hardware (HW) requirements, an UMR WQE is
> > initiated ahead of the GCM's GGA WQE to establish a continuous
> > AAD/Payload/Digest virtual memory space for the HW MMU.
> >
> > For IPsec scenarios, where the memory layout consistently adheres to
> > the fixed order of AAD/IV/Payload/Digest, directly shrinking memory
> > for AAD proves more efficient than preparing a UMR WQE. To address
> > this, a new devarg "crypto_mode" with mode "ipsec_opt" is introduced
> > in the commit, offering an optimization hint specifically for IPsec
> > cases. When enabled, the PMD copies AAD directly before Payload in the
> > enqueue_burst function instead of employing the UMR WQE. Subsequently,
> > in the dequeue_burst function, the overridden IV before Payload is
> > restored from the GGA WQE. It's crucial for users to avoid utilizing
> > the input mbuf data during processing.
> 
> This seems very specific to mlx5 and is not as per the expectations of cryptodev
> APIs.
> 
> It seems you are asking to alter the user application to accommodate this to
> support IPsec.
> 
> Cryptodev APIs are for generic crypto processing of data as defined in
> rte_crypto_op.
> With your proposed changes, it seems the behavior of the crypto APIs will be
> different in case of mlx5 which I believe is not correct.
> 
> Is it not possible for you to use rte_security IPsec path?
> 

Sorry I don't understand why that conflicts the API, IIUC crypto API only just defines the AAD/Payload/Digest in struct rte_crypto_sym_op, but not restrict the sequence, and AAD/Payload/Digest may come from difference memory space. Am I missing something here?
The input requirements from mlx5 HW is AAD/Payload/Digest sequence, if the input memory of AAD/Payload/Digest does not meet the requirements, PMD will try to combine the memory address space with UMR WQE as that commit does by software shrink.
And the most important thing is that "ipsec_opt" is not mandatory, only if user have such case of layout and allows that optimization happens. Otherwise, the existing UMR WQE will still be the default behavior here.

> > 2.34.1