From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH] eventdev: remove experimental label Date: Thu, 2 Nov 2017 09:41:53 +0530 Message-ID: <20171102041152.GA2107@jerin> References: <20171016103255.16322-1-jerin.jacob@caviumnetworks.com> <9184057F7FC11744A2107296B6B8EB1E1400BE33@FMSMSX108.amr.corp.intel.com> <20171030173803.GA9123@jerin> <9184057F7FC11744A2107296B6B8EB1E1400FA36@FMSMSX108.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" , "Richardson, Bruce" , "Van Haaren, Harry" , Hemant Agrawal , Nipun Gupta , "Rao, Nikhil" , Pavan Nikhilesh , Thomas Monjalon To: "Eads, Gage" Return-path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0079.outbound.protection.outlook.com [104.47.36.79]) by dpdk.org (Postfix) with ESMTP id C648A1B347 for ; Thu, 2 Nov 2017 05:12:15 +0100 (CET) Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E1400FA36@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, 1 Nov 2017 14:12:59 +0000 > From: "Eads, Gage" > To: Jerin Jacob > CC: "dev@dpdk.org" , "Richardson, Bruce" > , "Van Haaren, Harry" > , Hemant Agrawal , > Nipun Gupta , "Rao, Nikhil" , > Pavan Nikhilesh , Thomas Monjalon > > Subject: RE: [dpdk-dev] [PATCH] eventdev: remove experimental label > > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Monday, October 30, 2017 12:38 PM > > To: Eads, Gage > > Cc: dev@dpdk.org; Richardson, Bruce ; Van > > Haaren, Harry ; Hemant Agrawal > > ; Nipun Gupta ; Rao, > > Nikhil ; Pavan Nikhilesh > > ; Thomas Monjalon > > > > Subject: Re: [dpdk-dev] [PATCH] eventdev: remove experimental label > > > > -----Original Message----- > > > Date: Mon, 23 Oct 2017 18:27:52 +0000 > > > From: "Eads, Gage" > > > To: Jerin Jacob , "dev@dpdk.org" > > > > > > CC: "Richardson, Bruce" , "Van Haaren, Harry" > > > , Hemant Agrawal > > > , Nipun Gupta , "Rao, > > > Nikhil" , Pavan Nikhilesh > > > , Thomas Monjalon > > > > > > Subject: RE: [dpdk-dev] [PATCH] eventdev: remove experimental label > > > > > > Hi Jerin, > > > > Hi Gage, > > > > > > > > I have one concern with the API that may delay changing the label. > > > > > > The implicit release that in rte_event_dequeue_burst() is a problem when using > > asynchronous/look-aside hardware, like a cryptodev. For instance, let's say in > > pipeline stage N the worker takes the event's mbuf and places it in a per-worker > > crypto request queue. When the worker next calls rte_event_dequeue_burst(), > > that function will release the previous event which could cause the flow to > > migrate to another worker, and this could result in packet reordering. > > > > > > To prevent this, the worker can't call dequeue until the look-aside operation > > completes...in effect treating the asynchronous/look-aside hardware as > > synchronous. Another option is to feed stage N's queue to a single port to avoid > > the flow migration, but that port may become a bottleneck. > > > > > > We could remove the implicit release functionality or add a port configuration > > flag to disable it, so the default behavior is unchanged. Removing it will > > completely will likely require changes in existing code, but it simplifies the usage > > model (all dequeued events must be either forwarded or released) and the > > PMD's dequeue code. This functionality could be removed from the software > > eventdev fairly easily, but I haven't looked into the hardware PMDs. > > > > > > > > The HW implementations, I know, it does the implicit release. Otherwise it > > will result in deadlock because it cannot hold reordering metadata for > > the longtime(SRAM is limited etc) > > > > Coming back to cryptodev use case, if I understand it correctly, before > > application enqueues to crypto queue, the application will change the tag and > > submit to ATOMIC queue. So as long as crypto queue competes for the > > crypto work in order then the order will be maintained. > > > > In typical outbound IPSec use case, > > - Stage 1 will be processed in ORDERED where application does the SA > > lookup > > - Once SA found, application enqueue to ATOMIC stage with SA as flow_id. > > - When the event comes from the ATOMIC queue, it in ingress order and > > then it submits to the crypto queue > > - Crypto queue maintains the FIFO order. > > - On IPSec crypto work competition, packets will come in Stage 3. > > - So at Stage 3, packets are in ingress order for the given SA flow id. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Having said that, If SW implementation needs to do differently for performance > > reasons then we will end up in capability as HW implementation works in the > > implicit release. May we can sort out through capability or separate adapter for > > crypto case. But I think, those will be new additions to the API.So removing the > > experimental tags may be OK. > > But if you have strong opinion on keeping the experimental tag till we address > > the crypto use case then I am fine with that. > > > > Thoughts? > > Ok, agreed, no need to keep the tag for this concern. The capability idea is intriguing -- I'll chew on this and we can tackle it at a later point. OK. Please add Acked-by: > > Thanks, > Gage > > > > > Jerin > > > > > > > > > > Thanks, > > > Gage > > >