[EXT] [RFC PATCH 1/5] crypto/mlx5: add AES-GCM capability

[Suanming Mou]

> -----Original Message-----
> From: Akhil Goyal <gakhil at marvell.com>
> Sent: Wednesday, May 17, 2023 3:37 PM
> To: Suanming Mou <suanmingm at nvidia.com>; Matan Azrad
> <matan at nvidia.com>
> Cc: Raslan Darawsheh <rasland at nvidia.com>; Maayan Kashani
> <mkashani at nvidia.com>; dev at dpdk.org; NBU-Contact-Thomas Monjalon
> (EXTERNAL) <thomas at monjalon.net>
> Subject: RE: [EXT] [RFC PATCH 1/5] crypto/mlx5: add AES-GCM capability
> 
> > Subject: [EXT] [RFC PATCH 1/5] crypto/mlx5: add AES-GCM capability
> >
> > AES-GCM provides both authenticated encryption and the ability to
> > check the integrity and authentication of additional authenticated
> > data (AAD) that is sent in the clear.
> >
> > This commit adds the AES-GCM capability query and check. An new devarg
> > "algo" is added to identify if the crypto PMD will be initialized as
> > AES-GCM(algo=1) or AES-XTS(algo=0, default).
> 
> Why do you need a devarg for identifying the algorithm?
> Is it not sufficient to use enums rte_crypto_aead_algorithm and
> rte_crypto_cipher_algorithm?
> 
> Devargs are normally added for things which are specific to a particular PMD And
> which is not exposed via public APIs.
> For identification of algo, it is not needed to use devargs.
Due to current HW limitation, the NIC can only be initialized as GCM or XTS working mode during probe. It's not able to provide both in running time. That's the main reason for the devarg. 
Session configure with algo is too late.
> 
> >
> > Signed-off-by: Suanming Mou <suanmingm at nvidia.com>
> > ---