From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id D227E4C97 for ; Mon, 30 Jul 2018 11:15:24 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2018 02:15:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,422,1526367600"; d="scan'208";a="75683596" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga004.fm.intel.com with ESMTP; 30 Jul 2018 02:15:13 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.110]) by IRSMSX103.ger.corp.intel.com ([169.254.3.208]) with mapi id 14.03.0319.002; Mon, 30 Jul 2018 10:15:13 +0100 From: "Van Haaren, Harry" To: Jerin Jacob , "Elo, Matias (Nokia - FI/Espoo)" CC: "dev@dpdk.org" , "mattias.ronnblom@ericsson.com" Thread-Topic: eventdev: rte_event_dev_start() all queues are linked requirement Thread-Index: AQHUJ9hNxCmmwHvsL0+l1w2oHNJslqSnV5sAgAAgUsA= Date: Mon, 30 Jul 2018 09:15:13 +0000 Message-ID: References: <21037D32-C2B9-40FF-92E6-55F6FA725E24@nokia.com> <20180730080507.GA15830@jerin> In-Reply-To: <20180730080507.GA15830@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGIyNTAxNzQtZTdjMi00NWUzLThjNGEtOGZhMTJkMTJiNmQxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZXBuZ0lYS0dIaGZyWkFaUFU1RmNyS2VRTDlUd3BqcWtLc09GSkdGTzRVUXFJWGVVbFI3dUpDbk9VZVhiM0x0cSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] eventdev: rte_event_dev_start() all queues are linked requirement 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: Mon, 30 Jul 2018 09:15:25 -0000 > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Monday, July 30, 2018 9:05 AM > To: Elo, Matias (Nokia - FI/Espoo) > Cc: dev@dpdk.org; Van Haaren, Harry ; > mattias.ronnblom@ericsson.com > Subject: Re: eventdev: rte_event_dev_start() all queues are linked requir= ement >=20 > -----Original Message----- > > Date: Mon, 30 Jul 2018 07:38:27 +0000 > > From: "Elo, Matias (Nokia - FI/Espoo)" > > To: "dev@dpdk.org" > > CC: "jerin.jacob@caviumnetworks.com" , = "Van > > Haaren, Harry" > > Subject: eventdev: rte_event_dev_start() all queues are linked requirem= ent > > x-mailer: Apple Mail (2.3445.9.1) > > >=20 > + mattias.ronnblom@ericsson.com as his SW driver is scheduled for next > release. >=20 > > > > Hi, > > > > rte_event_dev_start() requires that all queues have to be linked, which > makes > > writing applications which link/unlink queues at runtime cumbersome. > > E.g. the application has to dummy link all queues before > rte_event_dev_start() > > and then unlink them after the function call. This alone wouldn't be a = big > issue > > but rte_event_dev_start() may also be called inside > > rte_event_eth_rx_adapter_create() implementation causing additional > complexity. > > > > To me this check seems more like eventdev implementation specific > limitation, > > which should be solved by the particular implementation and not enforce= d by > the > > API to all applications. From an application point of view enqueueing e= vents > to > > an unlinked queue and expecting something meaningful to happen is an er= ror > > anyway. So, would it be conceivable to remove this particular requireme= nt? >=20 > For HW drivers, It is OK remove the particular requirement. But, If > there is an issue(performance/functionality) for enabling such feature > in SW driver. I would like keep that constraint to keep eventdev as > abstraction for both SW and HW driver. Harry and/or Mattias.ronnblom can > comment from SW driver perspective. I don't have any objection to removing this restriction. Initially it was added to the event/sw driver as it avoids a potential deadlock situation if no ports are mapped to a queue, and the application enqueues events to the queue. As a result the queue will backpressure until the whole thing stops. I'm aware that this is incorrect usage - if events are enqueued to a queue the application is responsible for configuring the ports to pull those even= ts out again... we thought this would help the user - but it looks to do the o= pposite. Currently this is NOT enforced by the lib/eventdev layer (as far as I can s= ee)? I don't think the header file suggests such behavior either... In event/sw we have a check that fails - but we can relax that check. I'll wait a day or two for some more input, and send a patch for event/sw t= hen. Thanks @Matias Elo for bringing attention to this! -Harry