> On 12-Sep-25 2:05 PM, Akhil Goyal wrote: > > Hi Radu, > > > >> Update the API documentation description of rte_crypto_op field > >> aux_flags as to allow PMDs to define driver-specific flags. > > Can you give examples of the flags that you want to add for driver specific > work? > > I believe adding driver specific things here may not be good. > > May be we can discuss the specific flags and define them as common for all > PMDs. > > The flags we have in mind are very PMD specific i.e. controlling > specific hardware behavior so they will not be suitable to be added to > the common flags. > > Seeing that aux_flags are not that strongly defined and seeing that they > are already potentially used for PMD specific values my reasoning was to > formalize this possibility of usage > > aux_flags are used here to potentially carry a value that is not covered > in the common API aux_flags definitions: > > https://git.dpdk.org/dpdk/tree/drivers/crypto/cnxk/cn20k_cryptodev_ops.c#n857 > The aux flags that are currently defined are for soft expiry(out param) and TLS padding(in param). These are not PMD specific and are defined as generic flags passed by application Or getting more info about the crypto operation such as soft expiry which is not an error but will be useful for application to trigger rekeying in advance.
In your case, these flags need to be exposed if application is required to set. And we cannot define pmd specific flags in rte_crypto.h. Please specify use case if it can be useful for other PMDs also and we can add another flag. For PMD specific flags, is it not possible for you to use mbuf dynamic fields if it is an IPsec case? Or we can also explore to introduce dynfields in crypto_op. In above link, cop->aux_flags = res->uc_compcode; is set to give debug information to application, as warning codes are not exposed in crypto_op status. Application is not required to take any action based on the values other than the ones defined in rte_crypto.h. -Akhil
