From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Eads, Gage" <gage.eads@intel.com>
Cc: "Rao, Nikhil" <nikhil.rao@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Van Haaren, Harry" <harry.van.haaren@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
"Vangati, Narender" <narender.vangati@intel.com>,
"Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>
Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
Date: Thu, 3 Aug 2017 11:53:16 +0530 [thread overview]
Message-ID: <20170803062315.GA14704@jerin> (raw)
In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E01F00701@FMSMSX108.amr.corp.intel.com>
-----Original Message-----
> Date: Wed, 2 Aug 2017 19:19:32 +0000
> From: "Eads, Gage" <gage.eads@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Rao, Nikhil"
> <nikhil.rao@intel.com>
> CC: "dev@dpdk.org" <dev@dpdk.org>, "thomas@monjalon.net"
> <thomas@monjalon.net>, "Richardson, Bruce" <bruce.richardson@intel.com>,
> "Van Haaren, Harry" <harry.van.haaren@intel.com>, "hemant.agrawal@nxp.com"
> <hemant.agrawal@nxp.com>, "nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
> "Vangati, Narender" <narender.vangati@intel.com>, "Gujjar, Abhinandan S"
> <abhinandan.gujjar@intel.com>
> Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
>
>
> <snip>
>
> > > >
> > > > 5) specifying rte_event_eth_rx_adapter_conf.rx_event_port_id on
> > > > rte_event_eth_rx_adapter_create() would waste one HW eventdev port
> > > > if its happen to be used RX_ADAPTER_CAP_INBUILT_PORT on
> > rte_event_eth_rx_adapter_queue_add().
> > > > unlike SW eventdev port, HW eventdev ports are costly so I think, We
> > > > need to have another eventdev PMD ops to create service/producer ports.
> > > > Or any other scheme that creates
> > > > rte_event_eth_rx_adapter_conf.rx_event_port_id
> > > > on demand by common code.
> > > >
> > >
> > > One solution is:
> > >
> > > struct rte_event_eth_rx_adapter_conf {
> > > uint8_t dev_id;
> > >
> > > int (*conf_cb)(uint8_t id, uint8_t port_id, uint32_t flags, struct
> > > rte_event_eth_rx_adapter_conf *conf);
> > >
> > > unsigned int max_nb_rx;
> > >
> > > int event_port_id;
> > >
> > > char service_name[];
> > > }
> > >
> > > Where dev_id and conf_cb have to be specified in the create call, but
> > > event_port_id and service_name will be filled in when conf_cb() is
> > > invoked
> >
> > I was thinking like event_port_id will be rte_event_port_count() + 1.
> > ie When adapter needs the additional port, It can
> > - stop the eventdev
> > - reconfigure with rte_event_queue_count() , rte_event_port_count() + 1
> > - start the eventdev.
> >
> > The only problem with callback is that all the application needs to implement it.
> > If you think, application need more control then we can expose callback and if it
> > is NULL then default handler can be called in common code.
> >
>
> I don't think we can rely on there being another port available -- a user may have configured the sw eventdev with all 64 ports, for instance.
On that case, irrespective any scheme(callback vs non callback) the
adapter creation would fail. Right?
> What if the user is required to calculate cfg.nb_event_ports as a function of the RX_ADAPTER_CAP_INBUILT_PORT capability (i.e. add a port if the capability is not set), such that a reconfigure is not required?
We have only one NON INBUILT eventdev port per adapter. Right? i.e in the v1 spec it was rte_event_eth_rx_adapter_conf.event_port_id,
How about it can be rte_event_port_count() + 1 ? Since we are NOT
linking this port, the context call be kept in adapter itself. Right?
>
> As for application control: that would be a useful option in the conf_cb scheme. Some apps will want to configure the adapter's port (its new_event_threshold, its queue depths) differently from the default.
struct rte_event_port_conf * can be passed on the adapter create if
application needs more control.
>
> Thanks,
> Gage
next prev parent reply other threads:[~2017-08-03 6:23 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 20:38 [RFC] eventdev: add event adapter for ethernet Rx queues 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 ` [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
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 [this message]
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 ` [PATCH 2/2] eventdev: add event eth rx adapter unit tests Nikhil Rao
2017-07-24 10:10 ` [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=20170803062315.GA14704@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.