> ++Ram for openssl > > > ECDSA op: > > rte_crypto_param k; > > /**< The ECDSA per-message secret number, which is an integer > > * in the interval (1, n-1) > > */ > > DSA op: > > No 'k'. > > > > This one I think have described some time ago: > > Only PMD that verifies ECDSA is OCTEON which apparently needs 'k' provided > > by user. > > Only PMD that verifies DSA is OpenSSL PMD which will generate its own > > random number internally. > > > > So in case PMD supports one of these options (or especially when supports > > both) we need to give some information here.
We can have a standard way to represent if a particular rte_crypto_param is set by the application or not. Then, it is up to the PMD to perform the op or return error code if unable to proceed. > > > > The most obvious option would be to change rte_crypto_param k -> > > rte_crypto_param *k > > In case (k == NULL) PMD should generate it itself if possible, otherwise it > > should push crypto_op to the response ring with appropriate error code. This case could occur for other params as well. Having a few as nested variables and others as pointers could be confusing for memory alloc/dealloc. However, the rte_crypto_param already has a data pointer inside it which can be used in same manner. For example, in this case (k.data == NULL), PMD should generate random number if possible or push to response ring with error code. This can be done without breaking backward compatibility. This can be the standard way for PMDs to find if a particular rte_crypto_param is valid or NULL. > > > > Another options would be: > > - Extend rte_cryptodev_config and rte_cryptodev_info with information about > > random number generator for specific device (though it would be ABI > > breakage) > > - Provide some kind of callback to get random number from user (which could > > be useful for other things like RSA padding as well) I think the previous solution itself is more straightforward and simpler unless we want to have functionality to configure random number generator for each device. Thanks, Ramkumar Balu
