Hi,
I have some issues w.r.t the mapping sessions and queue pairs.
As per my understanding:
- Number of sessions may be large – they are independent of number of
queue pairs
- Queue pairs are L-core specific
- Depending on the implementation, one queue pair can be mapped to many
sessions. Or, Only one queue pair for every session- especially in the
systems having large number of queues (hw).
- Sessions can be created on the fly – typical rekeying use-cases.
Generally done by the control threads.
There seems to be no straight way for the underlying driver
implementation to know, what all sessions are mapped to a particular
queue pair. The session and queue pair information is first time exposed
in the enqueue command.
One of the NXP Crypto Hardware drivers uses per session data structures
(descriptors) which need to be configured for hardware queues. Though
this information can be extracted from the first enqueue command for a
particular session, it will add checks in the data path. Also, it will
bring down the connection setup rate.
In the API rte_cryptodev_sym_session_create(), we create session on a
particular device, but there is no information of queue pair being shared.
1. We want to propose to change the session create/config API to also
take queue pair id as argument.
struct rte_cryptodev_sym_session *
rte_cryptodev_sym_session_create(uint8_t dev_id,
struct rte_crypto_sym_xform *xform) to
also take “uint16_t qp;”
This will also return “in-use” error, if the underlying hardware only
support 1 session/descriptor per qp.
2. Currently the application configures the *nb_descriptors* in the
*rte_cryptodev_queue_pair_setup*. Should we add the queue pair
capability API?
Please share your feedback, I will submit the patch accordingly.
Regards,
Akhil
