From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 313B52E83 for ; Thu, 13 Jul 2017 05:26:52 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2017 20:26:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,352,1496127600"; d="scan'208";a="878258982" Received: from kchallax-mobl1.gar.corp.intel.com (HELO [10.252.148.114]) ([10.252.148.114]) by FMSMGA003.fm.intel.com with ESMTP; 12 Jul 2017 20:26:48 -0700 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 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> X-Mozilla-News-Host: news://proxy-fm.intel.com Message-ID: <4197b5f1-9a15-5892-12d2-6bd142bc4d85@intel.com> Date: Thu, 13 Jul 2017 08:56:48 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170710104126.GA13609@jerin> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 03:26:53 -0000 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) 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. 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 ? Nikhil