From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id A660D1B2D6 for ; Wed, 1 Nov 2017 15:13:01 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2017 07:13:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,329,1505804400"; d="scan'208";a="1238196233" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 01 Nov 2017 07:13:00 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 1 Nov 2017 07:13:00 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.115]) by FMSMSX102.amr.corp.intel.com ([169.254.10.148]) with mapi id 14.03.0319.002; Wed, 1 Nov 2017 07:13:00 -0700 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 Thread-Topic: [dpdk-dev] [PATCH] eventdev: remove experimental label Thread-Index: AQHTRmpTRlK6K7CWvkG/Xm4GCmCXCqL8vwomgALp7VA= Date: Wed, 1 Nov 2017 14:12:59 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E1400FA36@FMSMSX108.amr.corp.intel.com> References: <20171016103255.16322-1-jerin.jacob@caviumnetworks.com> <9184057F7FC11744A2107296B6B8EB1E1400BE33@FMSMSX108.amr.corp.intel.com> <20171030173803.GA9123@jerin> In-Reply-To: <20171030173803.GA9123@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWM0M2NiMmYtMjAyYS00MWFiLTllYWItZGQyYmZhMGY5OTE3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImVHNWZtRk5XbW02SkV5RWFFTFNcL0tJd0V3Z3ZwNWwwRlB5MU5jdzYwQ1dJPSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] eventdev: remove experimental label 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, 01 Nov 2017 14:13:03 -0000 > -----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 >=20 > -----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, Harr= y" > > , Hemant Agrawal > > , Nipun Gupta , "Rao, > > Nikhil" , Pavan Nikhilesh > > , Thomas Monjalon > > > > Subject: RE: [dpdk-dev] [PATCH] eventdev: remove experimental label > > > > Hi Jerin, >=20 > Hi Gage, >=20 > > > > 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 whe= n using > asynchronous/look-aside hardware, like a cryptodev. For instance, let's s= ay 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 ope= ration > completes...in effect treating the asynchronous/look-aside hardware as > synchronous. Another option is to feed stage N's queue to a single port t= o avoid > the flow migration, but that port may become a bottleneck. > > > > We could remove the implicit release functionality or add a port config= uration > flag to disable it, so the default behavior is unchanged. Removing it wil= l > completely will likely require changes in existing code, but it simplifie= s 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. >=20 >=20 >=20 > The HW implementations, I know, it does the implicit release. Otherwise i= t > will result in deadlock because it cannot hold reordering metadata for > the longtime(SRAM is limited etc) >=20 > 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. >=20 > 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > Having said that, If SW implementation needs to do differently for perfor= mance > reasons then we will end up in capability as HW implementation works in t= he > implicit release. May we can sort out through capability or separate adap= ter for > crypto case. But I think, those will be new additions to the API.So remov= ing the > experimental tags may be OK. > But if you have strong opinion on keeping the experimental tag till we ad= dress > the crypto use case then I am fine with that. >=20 > Thoughts? Ok, agreed, no need to keep the tag for this concern. The capability idea i= s intriguing -- I'll chew on this and we can tackle it at a later point. Thanks, Gage >=20 > Jerin >=20 >=20 > > > > Thanks, > > Gage > >