> > 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)
