DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	"Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Vangati, Narender" <narender.vangati@intel.com>,
	"Rao, Nikhil" <nikhil.rao@intel.com>,
	"Eads, Gage" <gage.eads@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"narayanaprasad.athreya@cavium.com"
	<narayanaprasad.athreya@cavium.com>,
	"nidadavolu.murthy@cavium.com" <nidadavolu.murthy@cavium.com>,
	"nithin.dabilpuram@cavium.com" <nithin.dabilpuram@cavium.com>
Subject: Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
Date: Mon, 26 Feb 2018 19:21:55 +0530	[thread overview]
Message-ID: <d9cc6973-4a49-a8c3-4141-cfa589b23139@nxp.com> (raw)
In-Reply-To: <20180220135920.GA23970@jerin>

Hi Jerin/Abhinandan,

On 2/20/2018 7:29 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Mon, 19 Feb 2018 10:55:58 +0000
>> From: "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>
>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>> CC: "dev@dpdk.org" <dev@dpdk.org>, "Vangati, Narender"
>>   <narender.vangati@intel.com>, "Rao, Nikhil" <nikhil.rao@intel.com>, "Eads,
>>   Gage" <gage.eads@intel.com>, "hemant.agrawal@nxp.com"
>>   <hemant.agrawal@nxp.com>, "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
>>   "narayanaprasad.athreya@cavium.com" <narayanaprasad.athreya@cavium.com>,
>>   "nidadavolu.murthy@cavium.com" <nidadavolu.murthy@cavium.com>,
>>   "nithin.dabilpuram@cavium.com" <nithin.dabilpuram@cavium.com>
>> Subject: RE: [RFC v2, 2/2] eventdev: add crypto adapter API header
>>
>> Hi Jerin,
> 
> Hi Abhinandan,
> 
>>
>> Thanks for the review. Please find few comments inline.
>>
>>> -----Original Message-----
>>> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
>>> Sent: Saturday, February 17, 2018 1:04 AM
>>> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
>>> Cc: dev@dpdk.org; Vangati, Narender <narender.vangati@intel.com>; Rao,
>>> Nikhil <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>;
>>> hemant.agrawal@nxp.com; akhil.goyal@nxp.com;
>>> narayanaprasad.athreya@cavium.com; nidadavolu.murthy@cavium.com;
>>> nithin.dabilpuram@cavium.com
>>> Subject: Re: [RFC v2, 2/2] eventdev: add crypto adapter API header
>>>
>>> -----Original Message-----
>>>> Date: Mon, 15 Jan 2018 16:23:50 +0530
>>>> From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
>>>> To: jerin.jacob@caviumnetworks.com
>>>> CC: dev@dpdk.org, narender.vangati@intel.com, Abhinandan Gujjar
>>>> <abhinandan.gujjar@intel.com>, Nikhil Rao <nikhil.rao@intel.com>, Gage
>>>> Eads <gage.eads@intel.com>
>>>> Subject: [RFC v2, 2/2] eventdev: add crypto adapter API header
>>>> X-Mailer: git-send-email 1.9.1
>>>>
>>>> +
>>>> +/**
>>>> + * This adapter adds support to enqueue crypto completions to event device.
>>>> + * The packet flow from cryptodev to the event device can be
>>>> +accomplished
>>>> + * using both SW and HW based transfer mechanisms.
>>>> + * The adapter uses a EAL service core function for SW based packet
>>>> +transfer
>>>> + * and uses the eventdev PMD functions to configure HW based packet
>>>> +transfer
>>>> + * between the cryptodev and the event device.
>>>> + *
>>>> + * In the case of SW based transfers, application can choose to
>>>> +submit a
>>>
>>> I think, we can remove "In the case of SW based transfers" as it should be
>>> applicable for HW case too
>> Ok. In that case, adapter will detect the presence of HW connection between
>> cryptodev & eventdev and will not dequeue crypto completions.
> 
> I would say presence of "specific capability" instead of HW.
> 
>>
>>>
>>>> + * crypto operation directly to cryptodev or send it  to the
>>>> + cryptodev
>>>> + * adapter via eventdev, the cryptodev adapter then submits the
>>>> + crypto
>>>> + * operation to the crypto device. The first mode is known as the
>>>
>>> The first mode (DEQ) is very clear. In the second mode(ENQ_DEQ),
>>> - How does "worker" submits the crypto work through crypto-adapter?
>>> If I understand it correctly, "workers" always deals with only cryptodev's
>>> rte_cryptodev_enqueue_burst() API and "service" function in crypto adapter
>>> would be responsible for dequeue() from cryptodev and enqueue to eventdev?
>>>
>>> I understand the need for OP_NEW vs OP_FWD mode difference in both modes.
>>> Other than that, What makes ENQ_DEQ different? Could you share the flow for
>>> ENQ_DEQ mode with APIs.
>>
>> /*
>> Application changes for ENQ_DEQ mode:
>> -------------------------------------------------
>> 	/* In ENQ_DEQ mode, to enqueue to adapter app
>> 	 * has to fill out following details.
>> 	 */
>> 	struct rte_event_crypto_request *req;
>> 	struct rte_crypto_op *op = rte_crypto_op_alloc();
>> 	
>> 	/* fill request info */
>> 	req = (void *)((char *)op + op.private_data_offset);
>> 	req->cdev_id = 1;
>> 	req->queue_pair_id = 1;
>>
>> 	/* fill response info */
>> 	...
>>
>> 	/* send event to crypto adapter */
>> 	ev->event_ptr = op;
>> 	ev->queue_id = dst_event_qid;
>> 	ev->priority = dst_priority;
>> 	ev->sched_type = dst_sched_type;
>> 	ev->event_type = RTE_EVENT_TYPE_CRYPTODEV;
>> 	ev->sub_event_type = sub_event_type;
>> 	ev->flow_id = dst_flow_id;
>> 	ret = rte_event_enqueue_burst(event_dev_id, event_port_id, ev, 1);
>>
>>
>> Adapter in ENQ_DEQ mode, submitting crypto ops to cryptodev:
>> -----------------------------------------------------------------------------
>> 	n = rte_event_dequeue_burst(event_dev_id, event_port_id, ev, BATCH_SIZE, time_out);
>> 	struct rte_crypto_op *op = ev->event_ptr;
>> 	struct rte_event_crypto_request *req = (void *)op + op.private_data_offset;
>> 	cdev_id = req->cdev_id;
>> 	qp_id = req->queue_pair_id
>>
>> 	ret = rte_cryptodev_enqueue_burst(cdev_id, qp_id, op, 1);
> 
> This mode wont work for the HW implementations that I know. As in HW
> implementations, The Adapter is embedded in HW.
> The DEQ mode works. But, This would call for to have two separate application logic for
> DEQ and ENQ_DEQ mode.
> I think, it is unavoidable as SW scheme has better performance with ENQ_DEQ MODE.
> 
> If you think, there is no option other than introducing a capability in
> adapter then please create capability in Rx adapter to inform the
> adapter capability to the application.
> 
> Do we think, it possible to have scheme with ENQ_DEQ mode, Where
> application still enqueue to cryptodev like DEQ mode but using
> cryptodev. ie. Adapter patches the cryptodev dev->enqueue_burst() to
> "eventdev enqueue burst" followed by "exiting dev->enqueue_burst".
> Something like exiting ethdev rx_burst callback scheme.
> This will enable application to have unified flow IMO.
> 
> Any thoughts from NXP folks?

I see that there is performance gain in sw side while using ENQ_DEQ 
mode. But since we already have many modes in the application already, 
can we make this one with some callback to cryptodev.

So the application can call the rte_cryptodev_enqueue_burst() as it is 
doing, and if the ENQ_DEQ mode is supported by the underneath 
implementation then, it can register a callback to the implementation 
that is required in the driver layer itself.

In this way, the application will become less complex as compared to the 
2 parallel implementations for SW and HW. It will also give more 
flexibility to the driver implementation as well.

-Akhil
> 
>> */
>>>
>>>> + * dequeue only (DEQ) mode  and the second as the enqueue - dequeue
>>>
>>> extra space between "mode" and "and"
>> Ok
>>>
>>>> + * (ENQ_DEQ) mode. The choice of mode can be specified when creating
>>>> + * the adapter.
>>>> + * In the latter choice, the cryptodev adapter is able to use
>>>> + * RTE_OP_FORWARD as the event dev enqueue type, this has a
>>>> + performance
>>>> + * advantage in "closed system" eventdevs like the eventdev SW PMD
>>>> + and
>>>
> 

  parent reply	other threads:[~2018-02-26 13:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 10:53 Abhinandan Gujjar
2018-02-13  9:21 ` Gujjar, Abhinandan S
2018-02-16 19:33 ` Jerin Jacob
2018-02-19 10:55   ` Gujjar, Abhinandan S
2018-02-20 13:59     ` Jerin Jacob
2018-02-20 18:55       ` Vangati, Narender
2018-02-21  6:54         ` Jerin Jacob
2018-02-23 12:00       ` Akhil Goyal
2018-02-26 13:51       ` Akhil Goyal [this message]
2018-02-28  9:01         ` Gujjar, Abhinandan S
2018-03-06  6:44           ` Akhil Goyal
2018-03-03 22:42         ` Vangati, Narender
2018-03-06  7:13           ` Akhil Goyal

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=d9cc6973-4a49-a8c3-4141-cfa589b23139@nxp.com \
    --to=akhil.goyal@nxp.com \
    --cc=abhinandan.gujjar@intel.com \
    --cc=dev@dpdk.org \
    --cc=gage.eads@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=narayanaprasad.athreya@cavium.com \
    --cc=narender.vangati@intel.com \
    --cc=nidadavolu.murthy@cavium.com \
    --cc=nikhil.rao@intel.com \
    --cc=nithin.dabilpuram@cavium.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).