[dpdk-dev] [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API

[Gujjar, Abhinandan S]

> -----Original Message-----
> From: Akhil Goyal <gakhil at marvell.com>
> Sent: Monday, April 5, 2021 11:11 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar at intel.com>; Shijith Thotton
> <sthotton at marvell.com>; dev at dpdk.org
> Cc: thomas at monjalon.net; Jerin Jacob Kollanukkaran <jerinj at marvell.com>;
> hemant.agrawal at nxp.com; nipun.gupta at nxp.com;
> sachin.saxena at oss.nxp.com; Anoob Joseph <anoobj at marvell.com>;
> matan at nvidia.com; Zhang, Roy Fan <roy.fan.zhang at intel.com>;
> g.singh at nxp.com; Carrillo, Erik G <erik.g.carrillo at intel.com>; Jayatheerthan,
> Jay <jay.jayatheerthan at intel.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula at marvell.com>; Van Haaren, Harry
> <harry.van.haaren at intel.com>
> Subject: RE: [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API
> 
> Hi Abhnandan,
> > >
> > > In case an event from a previous stage is required to be forwarded
> > > to a crypto adapter and PMD supports internal event port in crypto
> > > adapter, exposed via capability
> > > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, we do
> not have a
> > > way to check in the API rte_event_enqueue_burst(), whether it is for
> > > crypto adapter or for eth tx adapter.
> > I may be missing something here. Crypto adapter is an atomic stage has
> > a port which is setup during the adapter configuration.
> > So, application enqueuing events will end up sending to the crypto
> > adapter (As the adapter dequeues from a specific port).
> > Still wondering why there is requirement for new API.
> 
> While we do rte_event_enqueue_burst(), we do not have a way to identify
> whether The event is for crypto adapter or the eth adaptor.
> At the application layer, we know where to send the event, but in the event
> lib We do not know which port it need to be sent.
> IMO, event port is specifically designed to work for OP_NEW mode.
> I did not find a way to make it land into crypto adapter.
> Please let me know in case there is a better option other than adding a new
> API.
This looks like a hack as the new API does not actual enqueue events to eventdev.
Rather it directly extracts the crypto info from each event and then enqueue to cryptodev.

How about doing this (No changes to rte_event_enqueue_burst(), PMD takes care of things ):
uint16_t __rte_hot
ssows_enq_burst(void *port, const struct rte_event ev[], uint16_t nb_events)
{
+	struct otx2_ssogws *ws = port;
+
+	RTE_SET_USED(nb_events);
+
+	if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD)
+		return otx2_ca_enq(ws->tag_op, ev);

	return ssows_enq(port, ev);
}

Everything will be hidden under the callback and application will not have any changes.

> 
> >
> > >
> > > Hence we need a new API similar to
> > > rte_event_eth_tx_adapter_enqueue(),
> > > which can send to a crypto adapter.
> > >
> > > Note that RTE_EVENT_TYPE_* cannot be used to make that decision, as
> > > it is meant for event source and not event destination.
> > > And event port designated for crypto adapter is designed to be used
> > > for OP_NEW mode.
> > >
> > > Hence, in order to support an event PMD which has an internal event
> > > port
> > in
> > > crypto adapter (RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode),
> exposed
> > > via capability
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD,
> > > application should use rte_event_crypto_adapter_enqueue() API to
> > > enqueue events.
> > >
> > > When internal port is not
> > available(RTE_EVENT_CRYPTO_ADAPTER_OP_NEW
> > > mode), application can use API rte_event_enqueue_burst() as it was
> > > doing earlier, i.e. retrieve event port used by crypto adapter and
> > > bind its event queues to that port and enqueue events using the API
> > > rte_event_enqueue_burst().
> > >
> > > Signed-off-by: Akhil Goyal <gakhil at marvell.com>