From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Rao, Nikhil" <nikhil.rao@intel.com>
Cc: gage.eads@intel.com, dev@dpdk.org, thomas@monjalon.net,
bruce.richardson@intel.com, harry.van.haaren@intel.com,
hemant.agrawal@nxp.com, nipun.gupta@nxp.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: Fri, 14 Jul 2017 00:15:01 +0530 [thread overview]
Message-ID: <20170713184445.GA3659@jerin> (raw)
In-Reply-To: <4197b5f1-9a15-5892-12d2-6bd142bc4d85@intel.com>
-----Original Message-----
> Date: Thu, 13 Jul 2017 08:56:48 +0530
> From: "Rao, Nikhil" <nikhil.rao@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: gage.eads@intel.com, dev@dpdk.org, thomas@monjalon.net,
> bruce.richardson@intel.com, harry.van.haaren@intel.com,
> hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com,
> Abhinandan Gujjar <abhinandan.gujjar@intel.com>, nikhil.rao@intel.com
> Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.2.1
>
> On 7/10/2017 4:11 PM, Jerin Jacob wrote:
> > -----Original Message-----
> > >
> > > I also think that the application should be able to call create() with > 1
> > > ports. This would allow a single service to poll multiple NICs with WRR
> > > priority.
> >
> > Good point.
> >
> > Can we realize the same use case like below?
> > - Instead of applying WRR over multiple NIC ports and adding the logic in Rx
> > adapter, How about applying the WRR over multiple service function and
> > move the WRR logic to service function layer.
> >
> > i.e
> > one adapter is
> > - one service function(adapter_queue_add() will be used to add more
> > queues)
> > - one constant set of ops.
> >
> > Advantages:
> > - WRR over service functions will be useful as other service functions
> > can utilize it as it is not strictly specific to Rx adapter.
> > - In order to work with, below mentioned use cases, RX adapter ops needs
> > to be constant and it will decided on the _adapter_create where "eth_port_id"
> > and "dev_id" specified.
> >
> > 1) Ethdev HW is not capable of injecting the packets and SW eventdev
> > driver(All existing ethdev PMD + drivers/event/sw PMD combination)
> > 2) Ethdev HW is not capable of injecting the packets and not compatible
> > HW eventdev driver(All existing ethdev PMD + driver/event/octeontx PMD
> > combination)
> > 3) Ethdev HW is capable of injecting the packet to compatible
> > HW eventdev driver.
> >
> > - it will remove the below side effect(queue add/del API needs port_id)
> >
> > Thoughts?
>
> Re: Multiple ports within a adapter
>
> 1) 1:N adapter:port can work if the op is constant across all the
> ports (_adapter_create() gets to determine that)
Yes. But ops may not be constant, if we consider the above three models.
>
> WRR is specified on a per queue basis - The polling sequence
> built from the weights of all queues in the adapter (across all
> ports)
>
>
> struct rte_event_eth_rx_adapter_queue_conf {
> ...
> uint16_t servicing_weight;
> /**< Relative polling frequency of ethernet receive queue, if this
> * is set to zero, the Rx queue is interrupt driven (unless rx queue
> * interrupts are not enabled for the ethernet device)
> */
> ...
> }
>
> The downside is that a port needs to be specified when
> add/deleting a queue. Another thought is to do away with
> the concept of an adapter ID, and only use port IDs, but there
> is a possibility for 2 Rx queues of the same port to be
> associated with 2 different adapter IDs. from an API perspective
> you could specify any of ports[i] in the info/conf() APIs and
> that seems a bit odd.
>
> In summary, I agree, lets drop this idea.
OK. Great.
>
>
> 2) Re: Service function implementation of WRR
>
> Within a service like the Rx adapter the notion of WRR is
> relative polling frequency of the ethernet receive queue,
> polling a tap interface may be more heavy weight than the a HW
> NIC PMD poll, so WRR for the Rx adapter may not correlate with
> CPU utilization i.e, if that is a metric for some other service.
> If WRR is based on different metrics across services, I am not
> sure how we would able to specify WRR across services. Perhaps
> as services get more use, we maybe able to come up
> some common requirements.
>
> How about if multiple adapters can specify the same service,
> function in the _configure() call. A service can run multiple
> adapters with WRR across all queues in the service ?
Yes, It make sense. With ops scheme, multiple adapter can have same
service. But, I am not sure, what you really meant by "in _configure()"
call. But in any case, We can model around whatever scheme that works for SW PMD.
HW scheme will have constrain on "Multiple ports within a adapter",
Except that constraint, everything else we can model around SW PMD
requirements.
next prev parent reply other threads:[~2017-07-13 18:45 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 [this message]
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
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=20170713184445.GA3659@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).