From: Thomas Monjalon <thomas@monjalon.net>
To: Nithin Dabilpuram <ndabilpuram@marvell.com>
Cc: Olivier Matz <olivier.matz@6wind.com>,
Jerin Jacob <jerinjacobk@gmail.com>,
Nithin Dabilpuram <nithind1988@gmail.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Ori Kam <orika@mellanox.com>,
Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
John McNamara <john.mcnamara@intel.com>,
Marko Kovacevic <marko.kovacevic@intel.com>,
dpdk-dev <dev@dpdk.org>, Jerin Jacob <jerinj@marvell.com>,
Krzysztof Kanas <kkanas@marvell.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/3] mbuf: add Tx offloads for packet marking
Date: Fri, 15 May 2020 17:10:06 +0200 [thread overview]
Message-ID: <16221090.5WZRyvrzyv@thomas> (raw)
In-Reply-To: <20200515134420.GA9696@outlook.office365.com>
15/05/2020 15:44, Nithin Dabilpuram:
> On Fri, May 15, 2020 at 03:12:59PM +0200, Thomas Monjalon wrote:
> > 15/05/2020 12:08, Nithin Dabilpuram:
> > > On Thu, May 14, 2020 at 10:29:31PM +0200, Olivier Matz wrote:
> > > > I don't see any better approach than having a mbuf flag. However, I'm
> > > > still not fully convinced that a dynamic flag won't do the job. Taking
> > > > 3 additional flags (among 18 remaing) for this feature also means that
> > > > we have 3 flags less for dynamic flags for all applications, even for
> > > > applications that will not use this feature.
> > > >
> > > > Would it be a problem to use a dynamic flag in this case?
> > > Since packet marking feature itself is already part of spec,
> > > if we move the flags to PMD specific dynamic flag, then it creates a confusion.
> > >
> > > It is not the case of a custom feature supported by a specific PMD.
> > > I believe when other PMD's implement packet marking, the same flags will
> > > suffice.
> >
> > A dynamic flag is not necessarily PMD-specific.
> > It is just avoiding consuming bits if the feature is not used by the application.
> > We must move more existing flags and fields to be dynamic.
> >
> > In general, all new flags and fields in mbuf should be dynamic.
> > And a work must be done to move existing stuff to free more space
> > for more dynamic features.
>
> My bad, I thought dynamic flags can only be used for PMD specific thing.
>
> There is however a cost of using dynamic flag which I think should be avoided
> for DPDK spec defined offloads, though it's fine for PMD specific things.
>
> Dynamic offload flags causes application and PMD to use non constant offset
> or shift which are looked up at init, instead of having a constant shift or
> offset. This indirection costs some cycles due to extra loads in fast path.
Yes there is a cost. We described it quite clearly last year.
The default rule is now to add new flags and fields as dynamic.
In case the rule was not clear, I will send a patch to insert some
notes in the code and the doc.
If you disagree with this new rule, you will have to give very good arguments.
next prev parent reply other threads:[~2020-05-15 15:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 7:22 [dpdk-dev] " Nithin Dabilpuram
2020-04-17 7:22 ` [dpdk-dev] [PATCH 2/3] net/octeontx2: add tm packet marking cb Nithin Dabilpuram
2020-04-17 7:22 ` [dpdk-dev] [PATCH 3/3] net/octeontx2: add Tx packet marking offload support Nithin Dabilpuram
2020-05-01 11:18 ` [dpdk-dev] [PATCH 1/3] mbuf: add Tx offloads for packet marking Jerin Jacob
2020-05-04 8:06 ` Olivier Matz
2020-05-04 8:27 ` [dpdk-dev] [EXT] " Nithin Dabilpuram
2020-05-04 9:16 ` Olivier Matz
2020-05-04 10:04 ` Nithin Dabilpuram
2020-05-04 12:27 ` Olivier Matz
2020-05-05 6:19 ` Nithin Dabilpuram
2020-05-13 12:28 ` Nithin Dabilpuram
2020-05-14 20:29 ` Olivier Matz
2020-05-15 10:08 ` Nithin Dabilpuram
2020-05-15 10:30 ` Ananyev, Konstantin
2020-05-15 13:57 ` Nithin Dabilpuram
2020-05-28 15:43 ` Nithin Dabilpuram
2020-05-30 15:12 ` Jerin Jacob
2020-06-02 10:53 ` Ananyev, Konstantin
2020-06-02 14:25 ` Nithin Dabilpuram
2020-06-03 8:28 ` Olivier Matz
2020-06-03 10:44 ` Nithin Dabilpuram
2020-06-03 11:38 ` Olivier Matz
2020-06-03 12:52 ` Nithin Dabilpuram
2020-06-03 16:14 ` Slava Ovsiienko
2020-06-08 9:39 ` Nithin Dabilpuram
2020-06-03 14:56 ` Thomas Monjalon
2020-06-03 10:31 ` Ananyev, Konstantin
2020-05-15 13:12 ` Thomas Monjalon
2020-05-15 13:44 ` Nithin Dabilpuram
2020-05-15 15:10 ` Thomas Monjalon [this message]
2020-05-15 16:26 ` Jerin Jacob
2020-05-15 16:52 ` Thomas Monjalon
2020-05-15 17:00 ` Jerin Jacob
2020-05-15 18:07 ` Nithin Dabilpuram
2023-07-31 12:54 ` [dpdk-dev] " Thomas Monjalon
2023-08-14 8:11 ` Nithin Dabilpuram
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=16221090.5WZRyvrzyv@thomas \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=john.mcnamara@intel.com \
--cc=kkanas@marvell.com \
--cc=marko.kovacevic@intel.com \
--cc=ndabilpuram@marvell.com \
--cc=nithind1988@gmail.com \
--cc=olivier.matz@6wind.com \
--cc=orika@mellanox.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).