> -----Original Message-----
> From: Akhil Goyal <gak...@marvell.com>
> Sent: Wednesday, May 17, 2023 4:03 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: 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.
>
> That would fail even in current patchset.
> On another thought, is it not good to create 2 separate instances of drivers
> in
> same folder, like ipsec_mb and cnxk drivers are organized.
> You can change the function pointers based on the driver instance(mlx5_gcm,
> mlx5_xts)
Current, we are initial the capability based on the algo, so it will not fail.
Regarding separate the instance, yes, we will do that in the next version. We
will reuse the most of the common code in mlx5_crypto.c, mlx5_crypto_gcm.c for
GCM and mlx5_crypto_xts.c for XTS.
