From: "Eads, Gage" <gage.eads@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Vangati, Narender" <narender.vangati@intel.com>,
"Rao, Nikhil" <nikhil.rao@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"Doherty, Declan" <declan.doherty@intel.com>,
"nidadavolu.murthy@cavium.com" <nidadavolu.murthy@cavium.com>,
"nithin.dabilpuram@cavium.com" <nithin.dabilpuram@cavium.com>,
"narayanaprasad.athreya@cavium.com"
<narayanaprasad.athreya@cavium.com>
Subject: Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header
Date: Mon, 18 Dec 2017 16:33:53 +0000 [thread overview]
Message-ID: <9184057F7FC11744A2107296B6B8EB1E2BB29E9A@FMSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <20171218063012.GA12857@jerin>
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Monday, December 18, 2017 12:30 AM
> To: Eads, Gage <gage.eads@intel.com>
> Cc: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Vangati, Narender <narender.vangati@intel.com>; Rao, Nikhil
> <nikhil.rao@intel.com>; hemant.agrawal@nxp.com; Doherty, Declan
> <declan.doherty@intel.com>; nidadavolu.murthy@cavium.com;
> nithin.dabilpuram@cavium.com; narayanaprasad.athreya@cavium.com
> Subject: Re: [RFC] eventdev: add crypto adapter API header
>
> -----Original Message-----
> > Date: Thu, 14 Dec 2017 18:52:02 +0000
> > From: "Eads, Gage" <gage.eads@intel.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > CC: "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>, "dev@dpdk.org"
> > <dev@dpdk.org>, "Vangati, Narender" <narender.vangati@intel.com>,
> > "Rao, Nikhil" <nikhil.rao@intel.com>, "hemant.agrawal@nxp.com"
> > <hemant.agrawal@nxp.com>, "Doherty, Declan"
> > <declan.doherty@intel.com>, "nidadavolu.murthy@cavium.com"
> > <nidadavolu.murthy@cavium.com>, "nithin.dabilpuram@cavium.com"
> > <nithin.dabilpuram@cavium.com>, "narayanaprasad.athreya@cavium.com"
> > <narayanaprasad.athreya@cavium.com>
> > Subject: RE: [RFC] eventdev: add crypto adapter API header
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > Sent: Wednesday, December 13, 2017 8:49 PM
> > > To: Eads, Gage <gage.eads@intel.com>
> > > Cc: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>;
> > > dev@dpdk.org; Vangati, Narender <narender.vangati@intel.com>; Rao,
> > > Nikhil <nikhil.rao@intel.com>; hemant.agrawal@nxp.com; Doherty,
> > > Declan <declan.doherty@intel.com>; nidadavolu.murthy@cavium.com;
> > > nithin.dabilpuram@cavium.com; narayanaprasad.athreya@cavium.com
> > > Subject: Re: [RFC] eventdev: add crypto adapter API header
> > >
> > > -----Original Message-----
> > > > Date: Wed, 13 Dec 2017 23:35:48 +0000
> > > > From: "Eads, Gage" <gage.eads@intel.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>, "hemant.agrawal@nxp.com"
> <hemant.agrawal@nxp.com>, "Doherty, Declan"
> > > > <declan.doherty@intel.com>, "nidadavolu.murthy@cavium.com"
> > > > <nidadavolu.murthy@cavium.com>, "nithin.dabilpuram@cavium.com"
> > > > <nithin.dabilpuram@cavium.com>,
> "narayanaprasad.athreya@cavium.com"
> > > > <narayanaprasad.athreya@cavium.com>
> > > > Subject: RE: [RFC] eventdev: add crypto adapter API header
> > > >
> > > > Hey Jerin,
> > >
> > > Hey Gage,
> > >
> > > >
> > > > </snip>
> > > >
> > > > > > +
> > > > > > + /**
> > > > > > + * @warning
> > > > > > + * @b EXPERIMENTAL: this enum may change without prior notice
> > > > > > + *
> > > > > > + * Crypto event adapter type
> > > > > > + */
> > > > > > +enum rte_event_crypto_adapter_type {
> > > > > > + RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY = 1,
> > > > > > + /**< Start only Rx part of crypto adapter.
> > > > > > + * Packets dequeued from cryptodev are new to eventdev and
> > > > > > + * events will be treated as RTE_EVENT_OP_NEW */
> > > > > > + RTE_EVENT_CRYPTO_ADAPTER_RX_TX,
> > > > > > + /**< Start both Rx & Tx part of crypto adapter.
> > > > > > + * Packet's event context will be retained and
> > > > > > + * event will be treated as RTE_EVENT_OP_FORWARD */ };
> > > > >
> > > > > How about leveraging ev.op based schematics as mentioned above?
> > > >
> > > > That could work, but perhaps the ev.op should be configured once
> > > > up front, as
> > > I see it being a function of the application architecture. A couple
> > > possible designs, for example:
> > > > - Worker enqueues into cryptodev, adapter polls for response: the
> > > > adapter
> > > port would always use OP_NEW here.
> > > > - Worker sends a crypto request event to the adapter, which gives
> > > > the request to the cryptodev and polls for response: the adapter
> > > > port would always use OP_FWD here. (This ties in with my implicit
> > > > release patch
> > > > (http://dpdk.org/ml/archives/dev/2017-December/083535.html))
> > > > - Etc.
> > >
> > > Yes. Semantically both approaches will work. I was trying to avoid
> > > extra clutter(enum rte_event_crypto_adapter_type) in adapter API.
> > > I don't see any problem in moving ev.op to adapter configuration
> > > time if it helps the SW driver.
> > >
> > > IMO, We can change RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY and
> > > RTE_EVENT_CRYPTO_ADAPTER_RX_TX to more appropriate name,
> something
> > > like,
> RTE_EVENT_CRYPTO_ADAPTER_TYPE_OP_NEW/RTE_EVENT_CRYPTO_ADAPTE
> > > R_TYPE_OP_FWD
> > > or something like that.
> > >
> >
> > I agree that the two naming schemes are equivalent, but since this option
> would control the adapter's behavior (Rx only vs. Rx + Tx), (IMO) I think
> Abhinandan's original names do a better job of conveying what effect these two
> options have on the adapter, compared to the op type names.
>
> The only concern with Rx/Tx terminology was, It is mostly used in the ethdev
> domain.
> In crypto domain, typically, we use enqueue/dequeue.
> The only difference between two modes is if adapter enqueue the events with
> RTE_EVENT_OP_NEW vs RTE_EVENT_OP_FORWARD then (IMO) we can change
> something related to that name to avoid adding a new terminology.
>
Oh, sure -- enqueue/dequeue makes sense here. I'd still prefer DEQ_ONLY or DEQ_ENQ, but the event_op names work just as well.
Speaking of the crypto domain, the cryptodev enqueue and dequeue operations both take crypto op pointers. The original RFC had the request event pointing to an mbuf (which had a crypto_op pointer in its private metadata), but with the suggested opaque eventdev metadata changes it makes more sense for the request event to point to a crypto op. And the RFC didn't specify what the response event would point to (mbuf or crypto op), but to match the cryptodev dequeue operation then a crypto op makes sense. Will this work with your hardware?
> BTW, Based on the earlier discussion, if we need to add opaque eventdev
> metadata to cryptodev then it may change ABI.If so, I think, we need to
> announce ABI change notice for cryptodev and plan cryptodev adapter for
> v18.05.
Personally I'd prefer to get this right/agreed-upon the first time around -- even if that means breaking ABI and pushing this adapter out to 18.05.
next prev parent reply other threads:[~2017-12-18 16:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 6:54 Abhinandan Gujjar
2017-11-29 11:41 ` Jerin Jacob
2017-12-13 11:03 ` Doherty, Declan
2017-12-13 11:26 ` Jerin Jacob
2017-12-13 12:28 ` Nithin Dabilpuram
2017-12-13 14:29 ` Akhil Goyal
2017-12-13 14:22 ` Akhil Goyal
2017-12-13 17:37 ` Jerin Jacob
2017-12-13 23:35 ` Eads, Gage
2017-12-14 2:49 ` Jerin Jacob
2017-12-14 18:52 ` Eads, Gage
2017-12-18 6:30 ` Jerin Jacob
2017-12-18 16:33 ` Eads, Gage [this message]
2017-12-19 8:47 ` Jerin Jacob
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=9184057F7FC11744A2107296B6B8EB1E2BB29E9A@FMSMSX108.amr.corp.intel.com \
--to=gage.eads@intel.com \
--cc=abhinandan.gujjar@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--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).