> -----Original Message----- > From: Jerin Jacob [mailto:[email protected]] > Sent: Wednesday, December 13, 2017 8:49 PM > To: Eads, Gage <[email protected]> > Cc: Gujjar, Abhinandan S <[email protected]>; [email protected]; > Vangati, Narender <[email protected]>; Rao, Nikhil > <[email protected]>; [email protected]; Doherty, Declan > <[email protected]>; [email protected]; > [email protected]; [email protected] > Subject: Re: [RFC] eventdev: add crypto adapter API header > > -----Original Message----- > > Date: Wed, 13 Dec 2017 23:35:48 +0000 > > From: "Eads, Gage" <[email protected]> > > To: Jerin Jacob <[email protected]>, "Gujjar, Abhinandan S" > > <[email protected]> > > CC: "[email protected]" <[email protected]>, "Vangati, Narender" > > <[email protected]>, "Rao, Nikhil" <[email protected]>, > > "[email protected]" <[email protected]>, "Doherty, Declan" > > <[email protected]>, "[email protected]" > > <[email protected]>, "[email protected]" > > <[email protected]>, "[email protected]" > > <[email protected]> > > 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
