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