From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id C21712986 for ; Wed, 9 Aug 2017 04:23:21 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP; 08 Aug 2017 19:23:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,346,1498546800"; d="scan'208";a="121492572" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 08 Aug 2017 19:23:19 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 8 Aug 2017 19:23:17 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.74]) by fmsmsx156.amr.corp.intel.com ([169.254.13.192]) with mapi id 14.03.0319.002; Tue, 8 Aug 2017 19:23:16 -0700 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" Thread-Topic: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues Thread-Index: AQHS+UPHG57s3lsJOEGnOtNDEbj1IKJNVPuAgAQ9jgCAAQCMgIAVfkqAgANrvwCABElYAIAAhsAAgAICaceACSSv0A== Date: Wed, 9 Aug 2017 02:23:15 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E01F030FC@FMSMSX108.amr.corp.intel.com> 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> <20170803062315.GA14704@jerin> In-Reply-To: <20170803062315.GA14704@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWY0Y2NiOTYtNWFhOS00MzMzLThmYTgtY2JkOTIxM2VmZWNkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjVaYUVkTWtka01vM0hVZnhLdDF3ZVNqMlN0U0dXbjF0YWFxXC90VGpkY0RrPSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 09 Aug 2017 02:23:22 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Thursday, August 3, 2017 1:23 AM > To: Eads, Gage > 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 queu= es >=20 > -----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 i= mplement > 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 comm= on code. > > > > > > > I don't think we can rely on there being another port available -- a us= er may > have configured the sw eventdev with all 64 ports, for instance. >=20 > On that case, irrespective any scheme(callback vs non callback) the adapt= er > creation would fail. Right? >=20 > > What if the user is required to calculate cfg.nb_event_ports as a funct= ion of > the RX_ADAPTER_CAP_INBUILT_PORT capability (i.e. add a port if the capabi= lity > is not set), such that a reconfigure is not required? >=20 > 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 c= onfiguration without the application's knowledge. Possible issues that coul= d arise: - The user later reconfigures the event device with fewer ports and the ada= pter'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 capa= bilities for the CAP_ADD_QUEUE anyway, they could also check for INBUILT_PO= RT and decide whether or not to request an additional port at eventdev conf= igure 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. Besides these concerns, I think the transparent configuration approach (plu= s conf_cb when necessary to override) would work, but could have issues in = the aforementioned edge cases. > > > > As for application control: that would be a useful option in the conf_c= b > scheme. Some apps will want to configure the adapter's port (its > new_event_threshold, its queue depths) differently from the default. >=20 > struct rte_event_port_conf * can be passed on the adapter create if appli= cation > needs more control. >=20 > > > > Thanks, > > Gage