[dpdk-dev] [RFC] eventdev: add crypto adapter API header

Eads, Gage gage.eads at intel.com
Thu Dec 14 00:35:48 CET 2017


Hey Jerin,

</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.

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


More information about the dev mailing list