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: Thu, 10 Aug 2017 22:23:21 +0530 Message-ID: <20170810165319.GA6051@jerin> References: <20170713184445.GA3659@jerin> <123ed8d6-4fd9-8bee-d86e-d270a092169e@intel.com> <20170729151252.GA25166@jerin> <7b9ca757-f428-3675-b997-794ec6e96f2a@intel.com> <20170801164242.GA6467@jerin> <9184057F7FC11744A2107296B6B8EB1E01F00701@FMSMSX108.amr.corp.intel.com> <20170803062315.GA14704@jerin> <9184057F7FC11744A2107296B6B8EB1E01F030FC@FMSMSX108.amr.corp.intel.com> <20170809161946.GA6650@jerin> <9184057F7FC11744A2107296B6B8EB1E01F0EEF4@FMSMSX108.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Rao, Nikhil" , "dev@dpdk.org" , "thomas@monjalon.net" , "Richardson, Bruce" , "Van Haaren, Harry" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "Vangati, Narender" , "Gujjar, Abhinandan S" To: "Eads, Gage" Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0059.outbound.protection.outlook.com [104.47.38.59]) by dpdk.org (Postfix) with ESMTP id A9E0514E8 for ; Thu, 10 Aug 2017 18:53:47 +0200 (CEST) Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E01F0EEF4@FMSMSX108.amr.corp.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: Wed, 9 Aug 2017 19:24:30 +0000 > From: "Eads, Gage" > To: Jerin Jacob > CC: "Rao, Nikhil" , "dev@dpdk.org" , > "thomas@monjalon.net" , "Richardson, Bruce" > , "Van Haaren, Harry" > , "hemant.agrawal@nxp.com" > , "nipun.gupta@nxp.com" , > "Vangati, Narender" , "Gujjar, Abhinandan S" > > Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues > > > > > > > > > > > > > > > > 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? > > > > > > It could be. Thinking on it some more, I'm a little concerned about doing > > configuration without the application's knowledge. Possible issues that could > > arise: > > > - The user later reconfigures the event device with fewer ports and > > > the adapter's port becomes invalid, or reconfigures it with more ports > > > and begins using the port the adapter is using > > > - rte_event_port_count() + 1 extends beyond the PMD's capabilities > > > (the sw PMD is hard-coded to support a max of 64 ports, for example) > > > > > > Having the user be responsible for the port configuration could avoid these > > problems. Since the user needs to check the pair's > > capabilities for the CAP_ADD_QUEUE anyway, they could also check for > > INBUILT_PORT and decide whether or not to request an additional port at > > eventdev configure time -- thereby ensuring they don't waste a port when using > > hardware with inbuilt ports. And this keeps the configuration code in one place > > (the app), rather than spread across the app, adapter, and potentially the > > conf_cb. > > > > OK.Sounds reasonable.May be we can push the responsibility to application.We > > could have a helper function using the proposed adapter API. That helper > > function would create the adapter based on the capability for the _default_ > > case. > > Applications free to use the raw adapter API to get more control if required. > > Otherwise we will duplicate the code in all the applications. > > > > Makes sense. Are you thinking the helper function would do stop + reconfig with additional port + start + setup port, or just setup the port with an ID the app supplies (only when a port is required, of course)? The second one could be done with little additional code -- the app just needs to check if an additional port is needed when configuring the eventdev, and another helper function could take a list of pairs and return true if any don't have an inbuilt port. I am in favor adding more logic in helper function(I believe, first one ) so that it will help application reuse the helper functions for the normal case.