[dpdk-dev] cryptodev - Session and queue pair relationship

Akhil Goyal akhil.goyal at nxp.com
Mon Feb 6 14:35:22 CET 2017


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





More information about the dev mailing list