DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: "dev@dpdk.org" <dev@dpdk.org>,
	Declan Doherty <declan.doherty@intel.com>,
	 "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	<deepak.k.jain@intel.com>
Cc: "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>
Subject: [dpdk-dev] cryptodev - Session and queue pair relationship
Date: Mon, 6 Feb 2017 19:05:22 +0530	[thread overview]
Message-ID: <a1681853-e679-f2d1-c955-04abf1dee60b@nxp.com> (raw)

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

             reply	other threads:[~2017-02-06 13:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06 13:35 Akhil Goyal [this message]
2017-02-07 20:52 ` Declan Doherty
2017-02-13 14:38   ` Akhil Goyal
2017-02-13 14:44     ` Trahe, Fiona
2017-02-13 15:09       ` Trahe, Fiona
2017-02-14 11:43     ` Sergio Gonzalez Monroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1681853-e679-f2d1-c955-04abf1dee60b@nxp.com \
    --to=akhil.goyal@nxp.com \
    --cc=declan.doherty@intel.com \
    --cc=deepak.k.jain@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=pablo.de.lara.guarch@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).