> -----Original Message-----
> From: Akhil Goyal <gak...@marvell.com>
> Sent: Wednesday, May 17, 2023 3:37 PM
> To: Suanming Mou <suanmi...@nvidia.com>; Matan Azrad
> <ma...@nvidia.com>
> Cc: Raslan Darawsheh <rasl...@nvidia.com>; Maayan Kashani
> <mkash...@nvidia.com>; dev@dpdk.org; NBU-Contact-Thomas Monjalon
> (EXTERNAL) <tho...@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 <suanmi...@nvidia.com>
> > ---
