From: "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>
To: Akhil Goyal <gakhil@marvell.com>,
Shijith Thotton <sthotton@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
"sachin.saxena@oss.nxp.com" <sachin.saxena@oss.nxp.com>,
Anoob Joseph <anoobj@marvell.com>,
"matan@nvidia.com" <matan@nvidia.com>,
"Zhang, Roy Fan" <roy.fan.zhang@intel.com>,
"g.singh@nxp.com" <g.singh@nxp.com>,
"Carrillo, Erik G" <erik.g.carrillo@intel.com>,
"Jayatheerthan, Jay" <jay.jayatheerthan@intel.com>,
Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>,
"Van Haaren, Harry" <harry.van.haaren@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API
Date: Thu, 8 Apr 2021 16:57:17 +0000 [thread overview]
Message-ID: <DM6PR11MB3548790024D109CD495E6682E8749@DM6PR11MB3548.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MW2PR18MB2284BFA2D926E00650EE24F9D8749@MW2PR18MB2284.namprd18.prod.outlook.com>
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, April 8, 2021 8:27 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Shijith Thotton
> <sthotton@marvell.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> hemant.agrawal@nxp.com; nipun.gupta@nxp.com;
> sachin.saxena@oss.nxp.com; Anoob Joseph <anoobj@marvell.com>;
> matan@nvidia.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>;
> g.singh@nxp.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Jayatheerthan,
> Jay <jay.jayatheerthan@intel.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>
> Subject: RE: [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API
>
> 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.
>
> Regards,
> Akhil
> > >
> > > >
> > > > >
> > > > > 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@marvell.com>
next prev parent reply other threads:[~2021-04-08 16:58 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 18:12 [dpdk-dev] [PATCH] [RFC] " Akhil Goyal
2021-03-26 9:12 ` [dpdk-dev] [PATCH v1 0/2] Enhancements to crypto adapter forward mode Shijith Thotton
2021-03-26 9:12 ` [dpdk-dev] [PATCH v1 1/2] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-03-27 6:04 ` Pavan Nikhilesh Bhagavatula
2021-03-26 9:12 ` [dpdk-dev] [PATCH v1 2/2] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-03-27 6:27 ` Pavan Nikhilesh Bhagavatula
2021-03-29 4:31 ` Shijith Thotton
2021-03-29 15:04 ` [dpdk-dev] [PATCH v2 0/2] Enhancements to " Shijith Thotton
2021-03-29 15:04 ` [dpdk-dev] [PATCH v2 1/2] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-03-29 15:04 ` [dpdk-dev] [PATCH v2 2/2] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-04-02 15:03 ` [dpdk-dev] [PATCH v3 0/3] Enhancements to " Shijith Thotton
2021-04-02 15:03 ` [dpdk-dev] [PATCH v3 1/3] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-04-02 15:03 ` [dpdk-dev] [PATCH v3 2/3] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-04-02 15:03 ` [dpdk-dev] [PATCH v3 3/3] test/event_crypto: use crypto adapter enqueue API Shijith Thotton
2021-04-02 17:01 ` [dpdk-dev] [PATCH v4 0/3] Enhancements to crypto adapter forward mode Shijith Thotton
2021-04-02 17:01 ` [dpdk-dev] [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-04-03 12:32 ` Gujjar, Abhinandan S
2021-04-05 17:40 ` Akhil Goyal
2021-04-07 15:28 ` Gujjar, Abhinandan S
2021-04-08 14:56 ` Akhil Goyal
2021-04-08 16:57 ` Gujjar, Abhinandan S [this message]
2021-04-08 18:44 ` Akhil Goyal
2021-04-02 17:01 ` [dpdk-dev] [PATCH v4 2/3] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-04-03 10:20 ` Gujjar, Abhinandan S
2021-04-06 15:01 ` Anoob Joseph
2021-04-07 15:06 ` Gujjar, Abhinandan S
2021-04-08 6:45 ` Shijith Thotton
2021-04-02 17:01 ` [dpdk-dev] [PATCH v4 3/3] test/event_crypto: use crypto adapter enqueue API Shijith Thotton
2021-04-03 11:08 ` Gujjar, Abhinandan S
2021-04-05 6:10 ` Shijith Thotton
2021-04-08 19:24 ` [dpdk-dev] [PATCH v5 0/3] Enhancements to crypto adapter forward mode Shijith Thotton
2021-04-08 19:24 ` [dpdk-dev] [PATCH v5 1/3] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-04-08 19:24 ` [dpdk-dev] [PATCH v5 2/3] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-04-08 19:24 ` [dpdk-dev] [PATCH v5 3/3] test/event_crypto: use crypto adapter enqueue API Shijith Thotton
2021-04-09 14:00 ` [dpdk-dev] [PATCH v6 0/3] Enhancements to crypto adapter forward mode Shijith Thotton
2021-04-09 14:00 ` [dpdk-dev] [PATCH v6 1/3] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-04-09 14:00 ` [dpdk-dev] [PATCH v6 2/3] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-04-09 14:00 ` [dpdk-dev] [PATCH v6 3/3] test/event_crypto: use crypto adapter enqueue API Shijith Thotton
2021-04-12 5:10 ` Gujjar, Abhinandan S
2021-04-12 7:02 ` Shijith Thotton
2021-04-12 7:24 ` Gujjar, Abhinandan S
2021-04-12 7:35 ` Shijith Thotton
2021-04-12 13:52 ` Shijith Thotton
2021-04-12 15:00 ` Gujjar, Abhinandan S
2021-04-12 7:43 ` [dpdk-dev] [PATCH v7 0/3] Enhancements to crypto adapter forward mode Shijith Thotton
2021-04-12 7:43 ` [dpdk-dev] [PATCH v7 1/3] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-04-13 3:23 ` Gujjar, Abhinandan S
2021-04-12 7:43 ` [dpdk-dev] [PATCH v7 2/3] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-04-13 3:34 ` Gujjar, Abhinandan S
2021-04-13 8:51 ` Shijith Thotton
2021-04-12 7:43 ` [dpdk-dev] [PATCH v7 3/3] test/event_crypto: use crypto adapter enqueue API Shijith Thotton
2021-04-13 3:45 ` Gujjar, Abhinandan S
2021-04-13 10:29 ` [dpdk-dev] [PATCH v8 0/3] Enhancements to crypto adapter forward mode Shijith Thotton
2021-04-13 10:29 ` [dpdk-dev] [PATCH v8 1/3] eventdev: introduce crypto adapter enqueue API Shijith Thotton
2021-04-14 7:28 ` Jerin Jacob Kollanukkaran
2021-04-14 7:58 ` Akhil Goyal
2021-04-14 8:18 ` Thomas Monjalon
2021-04-14 8:39 ` [dpdk-dev] [EXT] " Akhil Goyal
2021-04-14 8:43 ` Thomas Monjalon
2021-04-14 12:20 ` [dpdk-dev] [PATCH v9 0/4] Enhancements to crypto adapter forward mode gakhil
2021-04-14 12:20 ` [dpdk-dev] [PATCH v9 1/4] eventdev: introduce crypto adapter enqueue API gakhil
2021-04-14 18:04 ` [dpdk-dev] [PATCH v10 0/4] Enhancements to crypto adapter forward mode gakhil
2021-04-14 18:04 ` [dpdk-dev] [PATCH v10 1/4] devtools: add exception for reserved fields gakhil
2021-04-14 20:57 ` David Marchand
2021-04-15 5:32 ` [dpdk-dev] [EXT] " Akhil Goyal
2021-04-15 7:26 ` David Marchand
2021-04-15 8:25 ` Bruce Richardson
2021-04-15 8:27 ` Thomas Monjalon
2021-04-15 8:31 ` Akhil Goyal
2021-04-15 19:56 ` Stephen Hemminger
2021-04-15 9:13 ` [dpdk-dev] [PATCH v11 0/3] Enhancements to crypto adapter forward mode gakhil
2021-04-15 9:13 ` [dpdk-dev] [PATCH v11 1/3] eventdev: introduce crypto adapter enqueue API gakhil
2021-04-17 16:54 ` Jerin Jacob
2021-04-15 9:13 ` [dpdk-dev] [PATCH v11 2/3] event/octeontx2: support crypto adapter forward mode gakhil
2021-04-15 9:13 ` [dpdk-dev] [PATCH v11 3/3] test/event_crypto: use crypto adapter enqueue API gakhil
2021-04-14 18:04 ` [dpdk-dev] [PATCH v10 2/4] eventdev: introduce " gakhil
2021-04-14 18:04 ` [dpdk-dev] [PATCH v10 3/4] event/octeontx2: support crypto adapter forward mode gakhil
2021-04-14 18:04 ` [dpdk-dev] [PATCH v10 4/4] test/event_crypto: use crypto adapter enqueue API gakhil
2021-04-14 12:20 ` [dpdk-dev] [PATCH v9 2/4] event/octeontx2: support crypto adapter forward mode gakhil
2021-04-14 12:20 ` [dpdk-dev] [PATCH v9 3/4] test/event_crypto: use crypto adapter enqueue API gakhil
2021-04-14 12:20 ` [dpdk-dev] [PATCH v9 4/4] devtools: add exception for reserved fields gakhil
2021-04-14 12:53 ` Thomas Monjalon
2021-04-14 14:16 ` [dpdk-dev] [EXT] " Akhil Goyal
2021-04-14 14:22 ` Thomas Monjalon
2021-04-14 17:56 ` Akhil Goyal
2021-04-13 10:29 ` [dpdk-dev] [PATCH v8 2/3] event/octeontx2: support crypto adapter forward mode Shijith Thotton
2021-04-13 10:29 ` [dpdk-dev] [PATCH v8 3/3] test/event_crypto: use crypto adapter enqueue API Shijith Thotton
2021-04-13 19:40 ` Jerin Jacob
2021-03-30 4:04 ` [dpdk-dev] [PATCH v1 0/2] Enhancements to crypto adapter forward mode Jerin Jacob
2021-03-30 4:57 ` Gujjar, Abhinandan S
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM6PR11MB3548790024D109CD495E6682E8749@DM6PR11MB3548.namprd11.prod.outlook.com \
--to=abhinandan.gujjar@intel.com \
--cc=anoobj@marvell.com \
--cc=dev@dpdk.org \
--cc=erik.g.carrillo@intel.com \
--cc=g.singh@nxp.com \
--cc=gakhil@marvell.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jay.jayatheerthan@intel.com \
--cc=jerinj@marvell.com \
--cc=matan@nvidia.com \
--cc=nipun.gupta@nxp.com \
--cc=pbhagavatula@marvell.com \
--cc=roy.fan.zhang@intel.com \
--cc=sachin.saxena@oss.nxp.com \
--cc=sthotton@marvell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).