From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues Date: Fri, 14 Jul 2017 00:15:01 +0530 Message-ID: <20170713184445.GA3659@jerin> References: <29140c16-909a-1b9a-7391-481f900bd13c@intel.com> <1499377952-5306-1-git-send-email-nikhil.rao@intel.com> <20170706141829.GA5260@jerin> <02aef899-da84-9281-e4a4-2871237ea20e@intel.com> <20170707150317.GA2007@jerin> <20170707155707.GA6245@jerin> <3d2d78cc-9572-bf95-6d25-9b350da62827@intel.com> <20170710104126.GA13609@jerin> <4197b5f1-9a15-5892-12d2-6bd142bc4d85@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 To: "Rao, Nikhil" Return-path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0078.outbound.protection.outlook.com [104.47.37.78]) by dpdk.org (Postfix) with ESMTP id 3546F2BAA for ; Thu, 13 Jul 2017 20:45:24 +0200 (CEST) Content-Disposition: inline In-Reply-To: <4197b5f1-9a15-5892-12d2-6bd142bc4d85@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Thu, 13 Jul 2017 08:56:48 +0530 > From: "Rao, Nikhil" > To: Jerin Jacob > 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 , 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.