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, 3 Aug 2017 11:53:16 +0530 Message-ID: <20170803062315.GA14704@jerin> References: <20170707155707.GA6245@jerin> <3d2d78cc-9572-bf95-6d25-9b350da62827@intel.com> <20170710104126.GA13609@jerin> <4197b5f1-9a15-5892-12d2-6bd142bc4d85@intel.com> <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> 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 NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0062.outbound.protection.outlook.com [104.47.33.62]) by dpdk.org (Postfix) with ESMTP id 0EF2B2C5E for ; Thu, 3 Aug 2017 08:23:46 +0200 (CEST) Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E01F00701@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, 2 Aug 2017 19:19:32 +0000 > From: "Eads, Gage" > To: Jerin Jacob , "Rao, Nikhil" > > CC: "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 > > > > > > > > > > > > 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