[dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done

Trahe, Fiona fiona.trahe at intel.com
Wed Jan 16 12:36:19 CET 2019


Hi Shally,

> -----Original Message-----
> From: Shally Verma [mailto:shallyv at marvell.com]
> Sent: Wednesday, January 16, 2019 11:22 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>;
> Verma, Shally <Shally.Verma at cavium.com>; Stephen Hemminger <stephen at networkplumber.org>
> Cc: dev at dpdk.org; akhil.goyal at nxp.com; Jozwiak, TomaszX <tomaszx.jozwiak at intel.com>; Gupta,
> Ashish <Ashish.Gupta at cavium.com>; Daly, Lee <lee.daly at intel.com>; Luse, Paul E
> <paul.e.luse at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>; Anoob Joseph
> <anoobj at marvell.com>; Tejasree Kondoj <ktejasree at marvell.com>
> Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done
> 
> Hi Pablo, Fiona
> 
> >-----Original Message-----
> >From: De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>
> >Sent: 11 January 2019 00:17
> >To: Trahe, Fiona <fiona.trahe at intel.com>; Verma, Shally <Shally.Verma at cavium.com>; Stephen
> Hemminger
> ><stephen at networkplumber.org>
> >Cc: dev at dpdk.org; akhil.goyal at nxp.com; Jozwiak, TomaszX <tomaszx.jozwiak at intel.com>; Gupta,
> Ashish
> ><Ashish.Gupta at cavium.com>; Daly, Lee <lee.daly at intel.com>; Luse, Paul E
> <paul.e.luse at intel.com>; Trahe, Fiona
> ><fiona.trahe at intel.com>
> >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 at dpdk.org] On Behalf Of Trahe, Fiona
> >> Sent: Wednesday, December 19, 2018 5:10 PM
> >> To: Verma, Shally <Shally.Verma at cavium.com>; Stephen Hemminger
> >> <stephen at networkplumber.org>
> >> Cc: dev at dpdk.org; akhil.goyal at nxp.com; Jozwiak, TomaszX
> >> <tomaszx.jozwiak at intel.com>; Gupta, Ashish <Ashish.Gupta at cavium.com>;
> >> Daly, Lee <lee.daly at intel.com>; Luse, Paul E <paul.e.luse at intel.com>; Trahe,
> >> Fiona <fiona.trahe at intel.com>
> >> Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to specify
> >> where processing is done
> >>
> >> Hi Shally,
> >>
> >> > -----Original Message-----
> >> > From: Verma, Shally [mailto:Shally.Verma at cavium.com]
> >> > Sent: Tuesday, December 18, 2018 10:48 PM
> >> > To: Trahe, Fiona <fiona.trahe at intel.com>; Stephen Hemminger
> >> > <stephen at networkplumber.org>
> >> > Cc: dev at dpdk.org; akhil.goyal at nxp.com; Jozwiak, TomaszX
> >> > <tomaszx.jozwiak at intel.com>; Gupta, Ashish
> >> <Ashish.Gupta at cavium.com>;
> >> > Daly, Lee <lee.daly at intel.com>; Luse, Paul E <paul.e.luse at intel.com>
> >> > Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to
> >> > specify where processing is done
> >> >
> >> >
> >> >
> >> > >-----Original Message-----
> >> > >From: Trahe, Fiona <fiona.trahe at intel.com>
> >> > >Sent: 18 December 2018 20:13
> >> > >To: Stephen Hemminger <stephen at networkplumber.org>
> >> > >Cc: dev at dpdk.org; akhil.goyal at nxp.com; Jozwiak, TomaszX
> >> > ><tomaszx.jozwiak at intel.com>; Verma,
> >> > Shally
> >> > ><Shally.Verma at cavium.com>; Gupta, Ashish
> >> <Ashish.Gupta at cavium.com>;
> >> > >Daly, Lee
> >> > <lee.daly at intel.com>; Luse, Paul E
> >> > ><paul.e.luse at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>
> >> > >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
> >> > >> > > <fiona.trahe at intel.com> 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 <fiona.trahe at intel.com>
> >> > >> > >
> >> > >> > > 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 latter
> >> > >> > 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 open
> >> > >> source project.  Hate to see more dead code and special cases created.
> >> > >>
> >> > >> At least, some example code in examples would help. Something like
> >> > >> 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 storage
> >> 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 up
> >> 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 SW only,
> >but it seems that you have another use case.
> 
> So, after having internal discussions, it is realized this feature will be 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 and wait for it to
> complete
> in enqueue itself to ensure in-order completion and then return. 
[Fiona] ok, I understand this point. I'll change the name to 
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 the app where it should wait?
This is a capability flag exported by the PMD, the appl can only query it to 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.
> 
> Thanks
> Shally
> 
> >
> >Thanks,
> >Pablo
> >
> >>
> >> > Thanks
> >> > Shally


More information about the dev mailing list