From: Olivier MATZ <olivier.matz@6wind.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, thomas@monjalon.net
Subject: Re: [dpdk-dev] [PATCH] mbuf: rename deprecated VLAN flags
Date: Tue, 24 Oct 2017 18:09:23 +0200 [thread overview]
Message-ID: <20171024160922.fu7qiciondyikgvb@platinum> (raw)
In-Reply-To: <4171e3c8-31eb-4c40-117b-87ac6a585764@intel.com>
Hi Ferruh,
On Mon, Oct 23, 2017 at 07:08:25PM -0700, Ferruh Yigit wrote:
> On 10/23/2017 5:16 AM, Olivier Matz wrote:
> > PKT_RX_VLAN_PKT and PKT_RX_QINQ_PKT are deprecated for a while.
> > As explained in [1], these flags were kept to let the applications and
> > PMDs move to the new flag. There is also a need to support Rx vlan
> > offload without vlan strip (at least for the ixgbe driver).
> >
> > This patch renames the old flags for this feature, knowing that some
> > PMDs were using PKT_RX_VLAN_PKT and PKT_RX_QINQ_PKT to indicate that
> > the vlan tci has been saved in the mbuf structure.
>
> So this patch merges two steps,
> - remove old flags
> - Add new flag to separate stripped and saved vlan info.
>
> Overall looks like a good idea.
>
> Just to confirm, in old usage, "PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED",
> both were meaning same thing, right. And "PKT_RX_VLAN_PKT" kept for backward
> compatibility.
> So previous "PKT_RX_VLAN_PKT" was way to say "stripped and saved", converting it
> to "PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED" as done in this patch should be safe.
> Only may be missing cases that only "PKT_RX_VLAN" is valid.
Before this patch:
- PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED: stripped and saved
- PKT_RX_VLAN_STRIPPED: unused, but also means stripped and saved
- PKT_RX_VLAN_PKT: undefined, but present in several drivers. In some of
them, I think it means 'not stripped and saved'.
After this patch:
- PKT_RX_VLAN: not stripped and saved
- PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED: stripped and saved
- PKT_RX_VLAN_STRIPPED: same (stripped and saved), PKT_RX_VLAN is implied
I think we can forbid to have this flag alone.
> And is "PKT_RX_VLAN_STRIPPED" implies the "PKT_RX_VLAN"? This was mentioned is
> the initial proposal, but it looks like that is not the case in this patch.
Yes, I can clarify it in the documentation.
> [...]
> > This patch has no impact on applications that do not
> > use the deprecated flags.
>
> I guess this is only true if "PKT_RX_VLAN_STRIPPED" implies the "PKT_RX_VLAN"
>From what I see, currently PKT_RX_VLAN_STRIPPED is always used
with PKT_RX_VLAN_PKT in PMDs, so I think there will be not impact.
> > For other applications, renaming
> > the flag would restore the same behavior.
>
> Not sure, for an old application, using "PKT_RX_VLAN_PKT", can't just rename to
> "PKT_RX_VLAN" and use as it is because now it doesn't say if vlan stripped or
> not. So old applications seems may be effected, if so this may require to be
> notified in advance.
Old applications using PKT_RX_VLAN_PKT have been notified
since 16.11 that the flag is deprecated.
If the application is relying on the undocumented fact that
PKT_RX_VLAN_PKT means "not stripped and saved" on some PMDs, it will
continue to work as is after renaming.
> > But, since we are
> > close to the release, applying it early after the release could
> > also be considered.
>
> Is there any benefit to be in this release, one think I can think of is 17.11
> being LTS, is there any other?
>
> And what do you think doing in two steps,
> - in this release remove deprecated flags
> - in the beginning of the next release introduce the new flags
I think one good side effect of having only one patch is that
it doesn't break applications that were using an undocumented
behavior of a PMD (it just requires a rename).
Olivier
next prev parent reply other threads:[~2017-10-24 16:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-23 12:16 Olivier Matz
2017-10-24 2:08 ` Ferruh Yigit
2017-10-24 16:09 ` Olivier MATZ [this message]
2017-10-25 0:42 ` Ferruh Yigit
2017-10-25 10:02 ` Olivier MATZ
2017-10-25 15:12 ` [dpdk-dev] [PATCH v2] " Olivier Matz
2017-10-25 17:42 ` Ferruh Yigit
2017-10-25 18:15 ` Ferruh Yigit
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=20171024160922.fu7qiciondyikgvb@platinum \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=thomas@monjalon.net \
/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).