From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 2029CF72 for ; Wed, 16 Jan 2019 12:36:26 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2019 03:36:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,485,1539673200"; d="scan'208";a="115083446" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga007.fm.intel.com with ESMTP; 16 Jan 2019 03:36:21 -0800 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.213]) by IRSMSX152.ger.corp.intel.com ([169.254.6.47]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 11:36:20 +0000 From: "Trahe, Fiona" To: Shally Verma , "De Lara Guarch, Pablo" , "Verma, Shally" , Stephen Hemminger CC: "dev@dpdk.org" , "akhil.goyal@nxp.com" , "Jozwiak, TomaszX" , "Gupta, Ashish" , "Daly, Lee" , "Luse, Paul E" , Anoob Joseph , Tejasree Kondoj , "Trahe, Fiona" Thread-Topic: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done Thread-Index: AQHUgHH0iBHC0Frsi0+jiJBhoUExD6VX5t6AgADy5OCAAB0HgIArxwTwgAD9/YCAALx38IAisHqAgAjxvACAAAHasA== Date: Wed, 16 Jan 2019 11:36:19 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B435896CAF10@IRSMSX101.ger.corp.intel.com> References: <1542677988-3876-1-git-send-email-fiona.trahe@intel.com> <20181119175349.2bd2fdd1@xeon-e3> <348A99DA5F5B7549AA880327E580B4358967C84F@IRSMSX101.ger.corp.intel.com> <20181120100703.34c462e9@xeon-e3> <348A99DA5F5B7549AA880327E580B435896A4B55@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435896A5DB3@IRSMSX101.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmRkMTBmOTUtYWI0My00Y2QyLWE2MGYtOTdkYWIzNGRjZjQ5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidG1abFBKQ1VKWXRzaGk2TXlXd28wSVVsK29OY0ZOOEhwSjBLam9lRGFlN0ozUmVRSDRMb2UzZ3NDdXRjNGJCbiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done 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, 16 Jan 2019 11:36:27 -0000 Hi Shally, > -----Original Message----- > From: Shally Verma [mailto:shallyv@marvell.com] > Sent: Wednesday, January 16, 2019 11:22 AM > To: De Lara Guarch, Pablo ; Trahe, Fiona = ; > Verma, Shally ; Stephen Hemminger > Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX ; Gupta, > Ashish ; Daly, Lee ; Luse, P= aul E > ; Trahe, Fiona ; Anoob Jose= ph > ; Tejasree Kondoj > Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify = where processing is done >=20 > Hi Pablo, Fiona >=20 > >-----Original Message----- > >From: De Lara Guarch, Pablo > >Sent: 11 January 2019 00:17 > >To: Trahe, Fiona ; Verma, Shally ; Stephen > Hemminger > > > >Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX ; Gupta, > Ashish > >; Daly, Lee ; Luse, Paul E > ; Trahe, Fiona > > > >Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify= where processing is done > > > >External Email > > > >Hi Shally, > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Trahe, Fiona > >> Sent: Wednesday, December 19, 2018 5:10 PM > >> To: Verma, Shally ; Stephen Hemminger > >> > >> Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX > >> ; Gupta, Ashish ; > >> Daly, Lee ; Luse, Paul E ; = Trahe, > >> Fiona > >> Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to speci= fy > >> where processing is done > >> > >> Hi Shally, > >> > >> > -----Original Message----- > >> > From: Verma, Shally [mailto:Shally.Verma@cavium.com] > >> > Sent: Tuesday, December 18, 2018 10:48 PM > >> > To: Trahe, Fiona ; Stephen Hemminger > >> > > >> > Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX > >> > ; Gupta, Ashish > >> ; > >> > Daly, Lee ; Luse, Paul E > >> > Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to > >> > specify where processing is done > >> > > >> > > >> > > >> > >-----Original Message----- > >> > >From: Trahe, Fiona > >> > >Sent: 18 December 2018 20:13 > >> > >To: Stephen Hemminger > >> > >Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX > >> > >; Verma, > >> > Shally > >> > >; Gupta, Ashish > >> ; > >> > >Daly, Lee > >> > ; Luse, Paul E > >> > >; Trahe, Fiona > >> > >Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to > >> > >specify where processing is done > >> > > > >> > >External Email > >> > > > >> > >Hi Stephen > >> > > > >> > >//snip// > >> > >> > > Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag > >> > >> > > to specify where processing is > >> > done > >> > >> > > > >> > >> > > On Tue, 20 Nov 2018 01:39:48 +0000 Fiona Trahe > >> > >> > > wrote: > >> > >> > > > >> > >> > > > A new device feature flag, > >> > >> > > > RTE_COMPDEV_FF_SW_OP_DONE_IN_DEQUEUE > >> > >> > > > is added. A PMD which processes operations using a software > >> > >> > > > acceleration engine should set this if the bulk of the > >> > >> > > > processing is done during the dequeue. It should leave it > >> > >> > > > cleared if the bulk of the processing is done during the > >> > >> > > > enqueue (default). > >> > >> > > > An application may find this useful for tuning. > >> > >> > > > > >> > >> > > > Signed-off-by: Fiona Trahe > >> > >> > > > >> > >> > > What application? or is this "if we build it they will come?" > >> > >> > [Fiona] Our storage team asked for this, so not quite. > >> > >> > Seems like it might by generically useful, so a bit of the latt= er > >> > >> > too :) Would you prefer I removed that line? > >> > >> > >> > >> Hopefully, there would be one or more open source projects using = the > >> API. > >> > >> I just did a survey of DPDK an 1/3 of it is never used by any ope= n > >> > >> source project. Hate to see more dead code and special cases cre= ated. > >> > >> > >> > >> At least, some example code in examples would help. Something lik= e > >> > >> a simple in memory compressed storage server using a network API > >> > >> (SMB?/SSH?/FTP?) > >> > >[Fiona] There is no compressdev sample app yet. > >> > >However I've double-checked with the SPDK team, they're currently > >> > >integrating compressdev and intend to push a patch to SPDK - a stor= age > >> open-source project - using this flag. > >> > [Shally] Am seeing some of our HW based PMD also leveraging this > >> > choice. So I would say to make it generic feature flag instead of SW= specific. > >> [Fiona] I can do but would like to understand this better first. > >> My understanding of HW offload is that the enqueue is just packaging u= p > >> the op and sending to the HW. > >> And the dequeue is just collecting the result from the HW and passing = back > >> to the op. > >> The work is done by the HW accelerator, in between those 2 API calls, = not > >> using any CPU cycles. > >> So what would it mean for HW to set OP_DONE_IN_DEQUEUE? > > > >Any comments on this? I agree with Fiona that this flag makes sense on S= W only, > >but it seems that you have another use case. >=20 > So, after having internal discussions, it is realized this feature will b= e useful for particular scenario in > HW also (though not very common > in practice but still in use). > Some hw based PMD, example current octeontx compression, enqueues an op a= nd wait for it to > complete > in enqueue itself to ensure in-order completion and then return.=20 [Fiona] ok, I understand this point. I'll change the name to=20 RTE_COMPDEV_FF_OP_DONE_IN_DEQUEUE to accommodate this. By giving this control to app, it can > dictate PMD whether > to wait for its completion in enqueue or dequeue. [Fiona] I'm not sure if this is a typo or not. You mean it can dictate to t= he app where it should wait? This is a capability flag exported by the PMD, the appl can only query it t= o see where the PMD does the work, NOT set it to tell the PMD where to do the work. This is useful where out-of-order completion of ops > negatively impact app > performance. Such app can use this flag to alter PMD behaviour. Also, we = have another PMD, where it > internally takes similar > flag to make this decision, having it exposed will make it more portable. >=20 > Thanks > Shally >=20 > > > >Thanks, > >Pablo > > > >> > >> > Thanks > >> > Shally