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

["Trahe, Fiona" <fiona.trahe@intel.com>]

Hi Shally,

> -----Original Message-----
> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
> Sent: Tuesday, December 18, 2018 10:48 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Stephen Hemminger <stephen@networkplumber.org>
> Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; Gupta,
> Ashish <Ashish.Gupta@cavium.com>; Daly, Lee <lee.daly@intel.com>; Luse, Paul E
> <paul.e.luse@intel.com>
> Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done
> 
> 
> 
> >-----Original Message-----
> >From: Trahe, Fiona <fiona.trahe@intel.com>
> >Sent: 18 December 2018 20:13
> >To: Stephen Hemminger <stephen@networkplumber.org>
> >Cc: dev@dpdk.org; akhil.goyal@nxp.com; Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; Verma,
> Shally
> ><Shally.Verma@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Daly, Lee
> <lee.daly@intel.com>; Luse, Paul E
> ><paul.e.luse@intel.com>; Trahe, Fiona <fiona.trahe@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@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@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?
 
> Thanks
> Shally