From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Nipun Gupta <nipun.gupta@nxp.com>
Cc: "Rao, Nikhil" <nikhil.rao@intel.com>,
"gage.eads@intel.com" <gage.eads@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"harry.van.haaren@intel.com" <harry.van.haaren@intel.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
"narender.vangati@intel.com" <narender.vangati@intel.com>,
Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Subject: Re: [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
Date: Mon, 31 Jul 2017 21:01:20 +0530 [thread overview]
Message-ID: <20170731153119.GA27245@jerin> (raw)
In-Reply-To: <HE1PR0401MB24253074D02A506B1881DA8BE6B20@HE1PR0401MB2425.eurprd04.prod.outlook.com>
> > - Theme is based on your original rx adapter proposal but with eventpmd
> > ops(not adapter ops).i.e Reuse as much of your existing Rx adapter
> > implementation as common code and add hooks for HW based adapters. For
> > example, before you add <ethdev, queue_id> to "rx_poll" in
> > eth_poll_wrr_calc(),
> > Check for eventdev PMD ops is available adding it HW. If yes, Don't add in
> > "rx_poll"
>
> This seems better approach. Infact we were also thinking on similar approach while
> reviewing the initial patch. This will also avoid redundant code for creation of services
> by separate event PMD's.
>
> >
> > adapter_api
> > ------------
> > int rte_event_eth_rx_adapter_create(id, rte_event_eth_rx_adapter_conf *conf)
> > int rte_event_eth_rx_adapter_queue_add(uint8_t id, uint8_t eth_dev_id, int32_t
> > rx_queue_id, rte_event_eth_rx_adapter_queue_conf *conf);
>
> Just wanted to know your opinion on adding other adapters such as for crypto devices.
>
> One way is to create separate adapter for crypto devices (or any other devices which may
> be linked with event devices). But this would again cause redundancy in service creations.
>
> In my opinion these API's can be independent of "_eth" suffix and have an enum of "device
> type" in adapter_capablity, queue_add and queue_delete API, so that the model is not
> limited for one type of device. For this series only ethernet type be supported but having
> possibility of adding other devices in future.
>
> Views on this?
For timer adapter, we will have fastpath API like , "arming" and "canceling"
the timers. IMO, semantically which will be different from eth_rx or
crypto adapter for the creation side.So may it be worth to have separate
adapter API for each subsystem to address the specific
requirements.(timer adapter may have resolution, max timeout etc
configuration parameters on adapter create())
>
next prev parent reply other threads:[~2017-07-31 15:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 20:38 [dpdk-dev] [RFC] " Gage Eads
2017-05-11 16:38 ` Jerin Jacob
2017-05-16 20:51 ` Thomas Monjalon
2017-05-24 4:30 ` Rao, Nikhil
2017-06-19 10:05 ` Jerin Jacob
2017-06-26 13:19 ` Jerin Jacob
2017-06-28 6:47 ` Rao, Nikhil
2017-07-06 21:52 ` [dpdk-dev] [PATCH 1/2] " Nikhil Rao
2017-07-06 14:18 ` Jerin Jacob
2017-07-07 6:21 ` Rao, Nikhil
2017-07-07 15:03 ` Jerin Jacob
2017-07-07 15:57 ` Jerin Jacob
2017-07-10 6:14 ` Rao, Nikhil
2017-07-10 10:41 ` Jerin Jacob
2017-07-13 3:26 ` Rao, Nikhil
2017-07-13 18:45 ` Jerin Jacob
2017-07-27 10:58 ` Rao, Nikhil
2017-07-29 15:12 ` Jerin Jacob
2017-07-31 3:57 ` Nipun Gupta
2017-07-31 15:31 ` Jerin Jacob [this message]
2017-08-01 8:40 ` Rao, Nikhil
2017-08-01 16:42 ` Jerin Jacob
2017-08-02 19:19 ` Eads, Gage
2017-08-03 6:23 ` Jerin Jacob
2017-08-09 2:23 ` Eads, Gage
2017-08-09 16:19 ` Jerin Jacob
2017-08-09 19:24 ` Eads, Gage
2017-08-10 16:53 ` Jerin Jacob
2017-08-14 8:48 ` Rao, Nikhil
2017-08-14 11:11 ` Jerin Jacob
2017-08-16 5:06 ` Rao, Nikhil
2017-08-11 5:25 ` Rao, Nikhil
2017-08-11 9:49 ` Jerin Jacob
2017-09-04 6:37 ` Jerin Jacob
2017-07-06 21:52 ` [dpdk-dev] [PATCH 2/2] eventdev: add event eth rx adapter unit tests Nikhil Rao
2017-07-24 10:10 ` [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues Nipun Gupta
2017-07-24 10:24 ` Jerin Jacob
2017-07-24 11:37 ` Nipun Gupta
2017-07-24 10:32 ` Van Haaren, Harry
2017-07-24 13:06 ` Nipun Gupta
2017-07-24 13:33 ` Van Haaren, Harry
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=20170731153119.GA27245@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=abhinandan.gujjar@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=narender.vangati@intel.com \
--cc=nikhil.rao@intel.com \
--cc=nipun.gupta@nxp.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).