DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: Vladimir Medvedkin <medvedkinv@gmail.com>,
	Dengdui Huang <huangdengdui@huawei.com>, <dev@dpdk.org>,
	<stephen@networkplumber.org>, <jasvinder.singh@intel.com>,
	<thomas@monjalon.net>, <aman.deep.singh@intel.com>,
	<lihuisong@huawei.com>, <fengchengwen@huawei.com>,
	<liuyonglong@huawei.com>
Subject: Re: [PATCH] net: support VLAN stacking packet type parsing
Date: Tue, 8 Jul 2025 11:16:26 +0100	[thread overview]
Message-ID: <aGzv-gld5GAFO2N0@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FD99@smartserver.smartshare.dk>

On Tue, Jul 08, 2025 at 12:00:42AM +0200, Morten Brørup wrote:
>    From: Vladimir Medvedkin [mailto:medvedkinv@gmail.com]
>    Sent: Monday, 7 July 2025 22.10
> 
> 
>    Hi Morten, all,
> 
> 
> 
>    пн, 7 июл. 2025 г. в 19:09, Morten Brørup
>    <[1]mb@smartsharesystems.com>:
> 
>      > From: Bruce Richardson [mailto:[2]bruce.richardson@intel.com]
>      > Sent: Friday, 4 July 2025 13.32
>      > Hi all,
>      >
>      > this email discussion comes at a bit of a fortunate time for me,
>      as I'm
>      > currently looking at our vlan tag/qinq stripping behaviour in our
>      Intel
>      > NIC
>      > drivers, and there is some discussion internally as to what our
>      driver
>      > behaviour should be compared to what it has historically been. :-)
>      >
>      > The documentation - both in the NIC guide [1] and the testpmd
>      guide [2]
>      > -
>      > is rather short on detail as to what exactly the behaviour should
>      be
>      > when
>      > vlan strip or qinq strip is implemented. Therefore, I'd hope that
>      those
>      > more familiar with networking than me would be able to help
>      clarify
>      > things
>      > so we can document the correct behaviour precisely - and hopefully
>      test
>      > our
>      > drivers against it in future!
>      >

<snipping full discussion for brevity>

So from the discussion, would the following be a good set of guidelines to
document for correct driver behaviour:

* VLAN-strip always strips one VLAN tag if available. If multiple VLAN tags
  are present, it strips the outer.
* QinQ strip, strips two VLAN tags if present. If only one tag is present it
  behaves as VLAN-strip.
* Specifying both VLAN-strip and QinQ strip is the same as QinQ strip alone (??)

Mbuf reporting behaviour:

Input Traffic		VLAN-strip on		QinQ strip on
--------------		-------------		-------------
Single VLAN pkts	Tag in mbuf->vlan_tci	Tag in mbuf->vlan_tci

Double VLAN pkts	Outer tag in vlan_tci	Outer tag in vlan_tci_outer
						Inner tag in vlan_tci 


Does the above seem reasonable and correct?

My one (minor)concern would be the handling and placement of the single tag
in the QinQ case. Depending on how the hardware treats a single tag in that
mode, the data path may have to pay a penalty if the HW takes a single VLAN
and places it in the "outer" position in the descriptor, since it needs to
go in the "inner" position in the mbuf, necessitating some conditional
logic.  AFAIK (subject to me actually testing for confirmation), this will
be the case for our Intel drivers.

/Bruce

  reply	other threads:[~2025-07-08 10:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03  9:30 Dengdui Huang
2025-07-04 10:18 ` Morten Brørup
2025-07-04 11:32   ` Bruce Richardson
2025-07-07 18:08     ` Morten Brørup
2025-07-07 20:10       ` Vladimir Medvedkin
2025-07-07 22:00         ` Morten Brørup
2025-07-08 10:16           ` Bruce Richardson [this message]
2025-07-08 15:07             ` Morten Brørup
2025-07-08 15:15               ` Bruce Richardson
2025-07-08 12:25           ` Medvedkin, Vladimir

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=aGzv-gld5GAFO2N0@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=huangdengdui@huawei.com \
    --cc=jasvinder.singh@intel.com \
    --cc=lihuisong@huawei.com \
    --cc=liuyonglong@huawei.com \
    --cc=mb@smartsharesystems.com \
    --cc=medvedkinv@gmail.com \
    --cc=stephen@networkplumber.org \
    --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).