DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shally Verma <shallyv@marvell.com>
To: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>,
	"Verma, Shally" <Shally.Verma@cavium.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"akhil.goyal@nxp.com" <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>,
	"Trahe, Fiona" <fiona.trahe@intel.com>,
	Anoob Joseph <anoobj@marvell.com>,
	Tejasree Kondoj <ktejasree@marvell.com>
Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done
Date: Wed, 16 Jan 2019 11:21:52 +0000	[thread overview]
Message-ID: <BN6PR1801MB20523B8F7034FB4F0330D9D1AD820@BN6PR1801MB2052.namprd18.prod.outlook.com> (raw)
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D89780362752@irsmsx112.ger.corp.intel.com>

Hi Pablo, Fiona

>-----Original Message-----
>From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>Sent: 11 January 2019 00:17
>To: Trahe, Fiona <fiona.trahe@intel.com>; Verma, Shally <Shally.Verma@cavium.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>; Trahe, Fiona
><fiona.trahe@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@dpdk.org] On Behalf Of Trahe, Fiona
>> Sent: Wednesday, December 19, 2018 5:10 PM
>> To: Verma, Shally <Shally.Verma@cavium.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>; Trahe,
>> Fiona <fiona.trahe@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@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?
>
>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. By giving this control to app, it can dictate PMD whether 
to wait for its completion in enqueue or dequeue.  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

  parent reply	other threads:[~2019-01-16 11:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20  1:39 Fiona Trahe
2018-11-20  1:53 ` Stephen Hemminger
2018-11-20 16:25   ` Trahe, Fiona
2018-11-20 18:07     ` Stephen Hemminger
2018-12-18 14:43       ` Trahe, Fiona
2018-12-19  5:47         ` Verma, Shally
2018-12-19 17:09           ` Trahe, Fiona
2019-01-10 18:46             ` De Lara Guarch, Pablo
2019-01-12  6:47               ` Verma, Shally
2019-01-16 11:21               ` Shally Verma [this message]
2019-01-16 11:36                 ` Trahe, Fiona
2019-01-16 12:09                   ` Shally Verma
2019-01-16 12:44                     ` Trahe, Fiona
2019-01-16 13:47                       ` Shally Verma
2018-11-20  5:17 ` Verma, Shally
2018-11-20 16:40   ` Trahe, Fiona
2019-01-17 17:36 ` [dpdk-dev] [PATCH v2] " Fiona Trahe
2019-02-20 16:00   ` Shally Verma
2019-03-22 15:09     ` Akhil Goyal
2019-03-22 15:09       ` Akhil Goyal
2018-12-18 18:41 [dpdk-dev] [PATCH] " Luse, Paul E

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN6PR1801MB20523B8F7034FB4F0330D9D1AD820@BN6PR1801MB2052.namprd18.prod.outlook.com \
    --to=shallyv@marvell.com \
    --cc=Ashish.Gupta@cavium.com \
    --cc=Shally.Verma@cavium.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=ktejasree@marvell.com \
    --cc=lee.daly@intel.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=paul.e.luse@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=tomaszx.jozwiak@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).