> -----Original Message----- > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Wednesday, December 13, 2017 8:49 PM > To: Eads, Gage <gage.e...@intel.com> > Cc: Gujjar, Abhinandan S <abhinandan.guj...@intel.com>; dev@dpdk.org; > Vangati, Narender <narender.vang...@intel.com>; Rao, Nikhil > <nikhil....@intel.com>; hemant.agra...@nxp.com; Doherty, Declan > <declan.dohe...@intel.com>; nidadavolu.mur...@cavium.com; > nithin.dabilpu...@cavium.com; narayanaprasad.athr...@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.e...@intel.com> > > To: Jerin Jacob <jerin.ja...@caviumnetworks.com>, "Gujjar, Abhinandan S" > > <abhinandan.guj...@intel.com> > > CC: "dev@dpdk.org" <dev@dpdk.org>, "Vangati, Narender" > > <narender.vang...@intel.com>, "Rao, Nikhil" <nikhil....@intel.com>, > > "hemant.agra...@nxp.com" <hemant.agra...@nxp.com>, "Doherty, Declan" > > <declan.dohe...@intel.com>, "nidadavolu.mur...@cavium.com" > > <nidadavolu.mur...@cavium.com>, "nithin.dabilpu...@cavium.com" > > <nithin.dabilpu...@cavium.com>, "narayanaprasad.athr...@cavium.com" > > <narayanaprasad.athr...@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. > > > > > So I think it makes sense to specify the op once at adapter configuration > > time, > rather than repeatedly in the datapath. This allows for a cleaner separation > of > configuration and datapath code, and specifying it just once means fewer > chances to accidentally set the wrong op value. > > > > Thanks, > > Gage
