On 12-Sep-25 3:56 PM, Akhil Goyal wrote:
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.
The application is not required to set these flags, the RFC change
specifically states "optional auxiliary flags".
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.
Yes, we can use dynfields and we can explore adding them to the crypto
op, but since we already have these flags we can make use of them.
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.
My proposal is very similar to this use case, just in the other
direction. The PMD is not required to take any action on the value of
aux_flags, and the application is not required to set anything.
-Akhil
