> -----Original Message-----
> From: Akhil Goyal <gak...@marvell.com>
> Sent: Wednesday, May 17, 2023 3:47 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: 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.
>
> Is it not possible to reconfigure the NIC when GCM is detected in session
> create?
That means in dev info, we need to put both XTS and GCM in the capability. But
the fact is if we reconfigure the NIC to GCM, XTS will not be supported. If
user wants to create both XTS and GCM session, one of them will fail.
>
