From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 09B3028C3 for ; Wed, 9 Aug 2017 21:24:32 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP; 09 Aug 2017 12:24:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,348,1498546800"; d="scan'208";a="888317113" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by FMSMGA003.fm.intel.com with ESMTP; 09 Aug 2017 12:24:31 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 9 Aug 2017 12:24:31 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.208]) by FMSMSX154.amr.corp.intel.com ([169.254.6.211]) with mapi id 14.03.0319.002; Wed, 9 Aug 2017 12:24:31 -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+UPHG57s3lsJOEGnOtNDEbj1IKJNVPuAgAQ9jgCAAQCMgIAVfkqAgANrvwCABElYAIAAhsAAgAICaceACSSv0IABZSWA//+yYdA= Date: Wed, 9 Aug 2017 19:24:30 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E01F0EEF4@FMSMSX108.amr.corp.intel.com> References: <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> <9184057F7FC11744A2107296B6B8EB1E01F030FC@FMSMSX108.amr.corp.intel.com> <20170809161946.GA6650@jerin> In-Reply-To: <20170809161946.GA6650@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzExYjU3ZGYtZDk0Ni00OWExLTg2MGEtOGY4MzFhYTBhNGEzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNi41LjkuMyIsIlRydXN0ZWRMYWJlbEhhc2giOiI4ZDB6eUR3Z3pVVG9zZmJMeU1MbmJ2TTBHVXI1R1NmVHo2c0xWU2NzZjZrPSJ9 x-ctpclassification: CTP_PUBLIC 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 19:24:33 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Wednesday, August 9, 2017 11:20 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, 9 Aug 2017 02:23:15 +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 > > > > > > > > > -----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 > > > queues > > > > > > -----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? > > > > It could be. Thinking on it some more, I'm a little concerned about doi= ng > configuration without the application's knowledge. Possible issues that c= ould > 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 t= hese > 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 th= e > conf_cb. >=20 > 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 _defaul= t_ > case. > Applications free to use the raw adapter API to get more control if requi= red. > 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 I= D the app supplies (only when a port is required, of course)? The second on= e 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 tr= ue if any don't have an inbuilt port.