* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
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
2 siblings, 1 reply; 13+ messages in thread
From: Vangati, Narender @ 2018-02-20 18:55 UTC (permalink / raw)
To: Jerin Jacob, Gujjar, Abhinandan S
Cc: dev, Rao, Nikhil, Eads, Gage, hemant.agrawal, akhil.goyal,
narayanaprasad.athreya, nidadavolu.murthy, nithin.dabilpuram
Jerin,
I see the "ENQ" part of the adapter a little differently. I think there is value to offloading cryptodev_enqueue to an adapter service, even when the h/w natively supports DEQ.
When the same queue pair is being used by the workers to enqueue requests (this could be where the pre crypto stage was ordered scheduled and the cryptodev enqueues need to be ordered), you would need some synchronization. Going thru eventdev to an adapter which enqueues on worker behalf provides that synchronization and ordering.
In that sense, the ENQ-DEQ mode is an application choice and defines its programming model. Based on that, a service would be created that does ENQ. For the DEQ part, perhaps the adapter can tell whether the h/w supports DEQ natively or needs to be done in s/w - that way you can have a single adapter.
Application model for DEQ mode - call cryptodev_enqueue directly. DEQ is h/w or s/w based on capability
Application model for ENQ-DEQ mode - use event_enqueue to offload cryptodev_enqueue to adapter. DEQ is h/w or s/w based on capability
vnr
---
-----Original Message-----
From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
Sent: Tuesday, February 20, 2018 7:59 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, 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?
> */
> >
> > > + * 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
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
2018-02-20 18:55 ` Vangati, Narender
@ 2018-02-21 6:54 ` Jerin Jacob
0 siblings, 0 replies; 13+ messages in thread
From: Jerin Jacob @ 2018-02-21 6:54 UTC (permalink / raw)
To: Vangati, Narender
Cc: Gujjar, Abhinandan S, dev, Rao, Nikhil, Eads, Gage,
hemant.agrawal, akhil.goyal, narayanaprasad.athreya,
nidadavolu.murthy, nithin.dabilpuram
-----Original Message-----
> Date: Tue, 20 Feb 2018 18:55:09 +0000
> From: "Vangati, Narender" <narender.vangati@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Gujjar, Abhinandan S"
> <abhinandan.gujjar@intel.com>
> CC: "dev@dpdk.org" <dev@dpdk.org>, "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 Narender,
> Jerin,
> I see the "ENQ" part of the adapter a little differently. I think there is value to offloading cryptodev_enqueue to an adapter service, even when the h/w natively supports DEQ.
But there is no element of _offload_ here. Right? meaning, We can express the ENQ-DEQ mode with existing cryptodev+eventdev normative API.
I think, Pushing to adapter will result in running ENQ-DEQ only on "service lcore" instead of "worker lcore".
How about making "ENQ-DEQ" scheme as set of helper C functions. This will enable,
1) To run the ENQ-DEQ logic in "service" or "worker" lcores
2) Remove the capability in adapter code. ie. If application wants to use ENQ-DEQ scheme
as a helper function it will work for both cases(HW and SW)
> When the same queue pair is being used by the workers to enqueue requests (this could be where the pre crypto stage was ordered scheduled and the cryptodev enqueues need to be ordered), you would need some synchronization. Going thru eventdev to an adapter which enqueues on worker behalf provides that synchronization and ordering.
Makes sense. Only question is that, do we need to expose as service function or generic helper C function?.
IMO, service functions makes sense when SW does something when there is no
HW support and to get the job done like schedule() function.
>
> In that sense, the ENQ-DEQ mode is an application choice and defines its programming model. Based on that, a service would be created that does ENQ. For the DEQ part, perhaps the adapter can tell whether the h/w supports DEQ natively or needs to be done in s/w - that way you can have a single adapter.
>
> Application model for DEQ mode - call cryptodev_enqueue directly. DEQ is h/w or s/w based on capability
> Application model for ENQ-DEQ mode - use event_enqueue to offload cryptodev_enqueue to adapter. DEQ is h/w or s/w based on capability
>
>
> vnr
> ---
>
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Tuesday, February 20, 2018 7:59 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, 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?
>
> > */
> > >
> > > > + * 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
> > >
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
2018-02-20 13:59 ` Jerin Jacob
2018-02-20 18:55 ` Vangati, Narender
@ 2018-02-23 12:00 ` Akhil Goyal
2018-02-26 13:51 ` Akhil Goyal
2 siblings, 0 replies; 13+ messages in thread
From: Akhil Goyal @ 2018-02-23 12:00 UTC (permalink / raw)
To: Jerin Jacob, Gujjar, Abhinandan S
Cc: dev, Vangati, Narender, Rao, Nikhil, Eads, Gage, hemant.agrawal,
narayanaprasad.athreya, nidadavolu.murthy, nithin.dabilpuram
Hi Folks,
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 would be replying on this on Monday.
>
>> */
>>>
>>>> + * 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
>>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
2018-02-20 13:59 ` Jerin Jacob
2018-02-20 18:55 ` Vangati, Narender
2018-02-23 12:00 ` Akhil Goyal
@ 2018-02-26 13:51 ` Akhil Goyal
2018-02-28 9:01 ` Gujjar, Abhinandan S
2018-03-03 22:42 ` Vangati, Narender
2 siblings, 2 replies; 13+ messages in thread
From: Akhil Goyal @ 2018-02-26 13:51 UTC (permalink / raw)
To: Jerin Jacob, Gujjar, Abhinandan S
Cc: dev, Vangati, Narender, Rao, Nikhil, Eads, Gage, hemant.agrawal,
narayanaprasad.athreya, nidadavolu.murthy, nithin.dabilpuram
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
>>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
2018-02-26 13:51 ` Akhil Goyal
@ 2018-02-28 9:01 ` Gujjar, Abhinandan S
2018-03-06 6:44 ` Akhil Goyal
2018-03-03 22:42 ` Vangati, Narender
1 sibling, 1 reply; 13+ messages in thread
From: Gujjar, Abhinandan S @ 2018-02-28 9:01 UTC (permalink / raw)
To: Akhil Goyal, Jerin Jacob
Cc: dev, Vangati, Narender, Rao, Nikhil, Eads, Gage, hemant.agrawal,
narayanaprasad.athreya, nidadavolu.murthy, nithin.dabilpuram
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Monday, February 26, 2018 7:22 PM
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>; 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; narayanaprasad.athreya@cavium.com;
> nidadavolu.murthy@cavium.com; nithin.dabilpuram@cavium.com
> Subject: Re: [RFC v2, 2/2] eventdev: add crypto adapter API header
>
> 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 ENQ-DEQ mode, crypto request are sent through the eventdev.
With your proposal, it is not clear how crypto request can be hidden under rte_cryptodev_enqueue_burst()!
Can you please share flow diagram or pseudo code?
-Abhinandan
>
> 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
> >>>
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
2018-02-28 9:01 ` Gujjar, Abhinandan S
@ 2018-03-06 6:44 ` Akhil Goyal
0 siblings, 0 replies; 13+ messages in thread
From: Akhil Goyal @ 2018-03-06 6:44 UTC (permalink / raw)
To: Gujjar, Abhinandan S, Jerin Jacob
Cc: dev, Vangati, Narender, Rao, Nikhil, Eads, Gage, hemant.agrawal,
narayanaprasad.athreya, nidadavolu.murthy, nithin.dabilpuram
Hi Abhinandan,
Sorry for the delayed response, my office network had some issues wrt
NNTP, so couldn't reply.
On 2/28/2018 2:31 PM, Gujjar, Abhinandan S wrote:
> Hi Akhil,
>
...<snip>...
>>>>>
>>>>>> + * 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 ENQ-DEQ mode, crypto request are sent through the eventdev.
> With your proposal, it is not clear how crypto request can be hidden under rte_cryptodev_enqueue_burst()!
> Can you please share flow diagram or pseudo code?
>
> -Abhinandan
>
The code flow is what Jerin also suggested.
"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."
The suggestion was just to simplify the flow in the application.
My main concern is that the ipsec-secgw application is already having a
lot of modes and we are about to add two more cases.
>>
>> 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
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
2018-02-26 13:51 ` Akhil Goyal
2018-02-28 9:01 ` Gujjar, Abhinandan S
@ 2018-03-03 22:42 ` Vangati, Narender
2018-03-06 7:13 ` Akhil Goyal
1 sibling, 1 reply; 13+ messages in thread
From: Vangati, Narender @ 2018-03-03 22:42 UTC (permalink / raw)
To: Akhil Goyal, Jerin Jacob, Gujjar, Abhinandan S
Cc: dev, Rao, Nikhil, Eads, Gage, hemant.agrawal,
narayanaprasad.athreya, nidadavolu.murthy, nithin.dabilpuram
Akhil,
I'm probably missing a point somewhere but I don't follow the suggestions. To me, ethdev, cryptodev, eventdev, etc. are device abstractions, whereas the proposed ENQ mode isn't at the same level.
The DEQ mode is a device abstraction for cryptodev->eventdev (whether h/w or s/w based), but the ENQ part of the adapter is purely a s/w programming model and optional to the application. It is independent of any device and it’s an application choice whether it wants to use this or not. Nothing prevents the application from calling cryptodev_enqueue_burst towards any device directly (whether it be soft crypto, NXP, Cavium, QAT, etc ) within an eventdev based environment.
The ENQ mode allows an application programming model to be completely event based. If the application chooses, it enables the ENQ part where it enqueues an rte_event to the s/w adapter and the adapter then calls cryptodev_enqueue_burst on its behalf, towards any device PMD which was created.
There are certain benefits to application architecture using this adapter where you can leverage the ordered scheduling within eventdev etc., (and certain cons where you need to run this service somewhere) but that’s up to the application to decide.
In other words, I don’t consider ENQ mode as a device abstraction like cryptodev or ethdev where it needs to plug in to something transparently but a programming model that is provided as a choice, and that shouldn’t be tied up into a device abstraction layer.
vnr
---
-----Original Message-----
From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
Sent: Monday, February 26, 2018 7:52 AM
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>; 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; narayanaprasad.athreya@cavium.com; nidadavolu.murthy@cavium.com; nithin.dabilpuram@cavium.com
Subject: Re: [RFC v2, 2/2] eventdev: add crypto adapter API header
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
>>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
2018-03-03 22:42 ` Vangati, Narender
@ 2018-03-06 7:13 ` Akhil Goyal
0 siblings, 0 replies; 13+ messages in thread
From: Akhil Goyal @ 2018-03-06 7:13 UTC (permalink / raw)
To: Vangati, Narender, Jerin Jacob, Gujjar, Abhinandan S
Cc: dev, Rao, Nikhil, Eads, Gage, hemant.agrawal,
narayanaprasad.athreya, nidadavolu.murthy, nithin.dabilpuram
Hi Narender,
On 3/4/2018 4:12 AM, Vangati, Narender wrote:
> Akhil,
> I'm probably missing a point somewhere but I don't follow the suggestions. To me, ethdev, cryptodev, eventdev, etc. are device abstractions, whereas the proposed ENQ mode isn't at the same level.
> The DEQ mode is a device abstraction for cryptodev->eventdev (whether h/w or s/w based), but the ENQ part of the adapter is purely a s/w programming model and optional to the application. It is independent of any device and it’s an application choice whether it wants to use this or not. Nothing prevents the application from calling cryptodev_enqueue_burst towards any device directly (whether it be soft crypto, NXP, Cavium, QAT, etc ) within an eventdev based environment.
> The ENQ mode allows an application programming model to be completely event based. If the application chooses, it enables the ENQ part where it enqueues an rte_event to the s/w adapter and the adapter then calls cryptodev_enqueue_burst on its behalf, towards any device PMD which was created.
> There are certain benefits to application architecture using this adapter where you can leverage the ordered scheduling within eventdev etc., (and certain cons where you need to run this service somewhere) but that’s up to the application to decide.
>
> In other words, I don’t consider ENQ mode as a device abstraction like cryptodev or ethdev where it needs to plug in to something transparently but a programming model that is provided as a choice, and that shouldn’t be tied up into a device abstraction layer.
>
> vnr
I am not against of eventdev enqueue API, or let the application decide
to use it or not.
I am trying to limit more options in already multi-option IPSEC
usecases. It is getting too confusing.
Also, my concern is that sw based crypto-event can also follow the same
path as the hw based in this case. This will help the application to
have a common code for both the cases.
-Akhil
> ---
>
>
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Monday, February 26, 2018 7:52 AM
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>; 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; narayanaprasad.athreya@cavium.com; nidadavolu.murthy@cavium.com; nithin.dabilpuram@cavium.com
> Subject: Re: [RFC v2, 2/2] eventdev: add crypto adapter API header
>
> 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
>>>>
>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread