DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: "Verma, Shally" <Shally.Verma@cavium.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "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>,
	"Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done
Date: Tue, 20 Nov 2018 16:40:59 +0000	[thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B4358967C891@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <SN6PR07MB515273FA80AC9D45469C3E24F0D90@SN6PR07MB5152.namprd07.prod.outlook.com>

Hi Shally,

> -----Original Message-----
> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
> Sent: Monday, November 19, 2018 10:17 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; Gupta, Ashish
> <Ashish.Gupta@cavium.com>; Daly, Lee <lee.daly@intel.com>
> Subject: RE: [PATCH] compressdev: add feature flag to specify where processing is done
> 
> HI Fiona
> 
> >-----Original Message-----
> >From: Fiona Trahe <fiona.trahe@intel.com>
> >Sent: 20 November 2018 07:10
> >To: dev@dpdk.org
> >Cc: akhil.goyal@nxp.com; tomaszx.jozwiak@intel.com; Verma, Shally <Shally.Verma@cavium.com>;
> Gupta, Ashish
> ><Ashish.Gupta@cavium.com>; lee.daly@intel.com; fiona.trahe@intel.com
> >Subject: [PATCH] compressdev: add feature flag to specify where processing is done
> >
> >External Email
> >
> >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.
> 
> Help me understand a bit , so how does it work when:
> 1. PMD do ops processing only at enqueue , will not set this flag?
> 2. PMD do ops processing only at dequeue, then?
> 3. PMD can do op processing both at enqueue and dequeue and in such case,  can set this flag to indicate
> this support? So that app can choose?
[Fiona] Both sw PMDs already upstreamed do the bulk of the work on the enqueue.
So no need to set the flag.
It doesn't seem likely that PMDs will split the workload between enqueue and dequeue, if they do for some reason, thy can set whichever makes most sense.
It's like a hint, similar to the HW flag - to help an application to tune - applications don't have to use it if they don't want to.
I'm planning to send same patch for cryptodev - there two PMDs do all the work on dequeue, the rest do it on enqueue. Our Storage team asked for this as they changed some polling timings once they understood
where the work was done.

 
> if supported then app set this feature flag on PMD and PMD take it as a hint to know application
> preference of processing point or PMD always do bulk processing at chosen point?
[Fiona] No, it's the opposite - the PMD reports the capabilities to the appl.
> 
> And why specific to SW PMD, I see HW PMD can do use this feature flag?!
[Fiona] HW is not using CPU cycle as the work is offloaded, so I don't see how it can apply there.



> 
> Thanks
> Shally

  reply	other threads:[~2018-11-20 16:41 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
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 [this message]
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=348A99DA5F5B7549AA880327E580B4358967C891@IRSMSX101.ger.corp.intel.com \
    --to=fiona.trahe@intel.com \
    --cc=Ashish.Gupta@cavium.com \
    --cc=Shally.Verma@cavium.com \
    --cc=akhil.goyal@nxp.com \
    --cc=dev@dpdk.org \
    --cc=lee.daly@intel.com \
    --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).