[dpdk-dev] [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API
Akhil Goyal
gakhil at marvell.com
Thu Apr 8 20:44:50 CEST 2021
> > Hi Abhinandan,
> > > > > >
> > > > > > 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.
> > >
> > You want to say we somehow save a flag in struct otx2_ssogws from the
> > capability And check that flag here to enq to crypto. But that will not work,
> as
> > the events coming In this API can be for both crypto as well as eth tx
> adapter.
> > If this check is there, all events will go to crypto adapter.
> >
> > In the library or the driver, we do not have a mechanism to determine the
> > destination of the event (Note that event type is for source of event and
> not
> > destination).
> > Using some fields of rte_event will be a hack IMO.
> >
> > The solution proposed in this patchset is not a hack. Here is a reasoning to
> it:
> > - The application when dequeues an event from the previous stage, knows
> > what to do with the event - send it to crypto or send to ethernet. Hence it
> > makes sense to call the different API there itself as inside the
> > rte_event_enqueue_burst() there is no way to determine if it is for crypto
> > adapter or eth adapter.
> > Moreover, the solution is very similar to what eth tx adapter already
> support
> > (a new API to enqueue).
> >
> > I hope this make things clearer now.
> Yes Akhil. This makes it more clear. Thanks for clarifying.
Do you have any further comments on this patchset? If not, could you please ack it?
More information about the dev
mailing list