From: huangdengdui <huangdengdui@huawei.com>
To: "Morten Brørup" <mb@smartsharesystems.com>, dev@dpdk.org
Cc: <stephen@networkplumber.org>, <jasvinder.singh@intel.com>,
<thomas@monjalon.net>, <aman.deep.singh@intel.com>,
<lihuisong@huawei.com>, <fengchengwen@huawei.com>,
liuyonglong <liuyonglong@huawei.com>
Subject: Re: Does rte_net_get_ptype() support processing packets with two 0x8100 VLAN tags?
Date: Wed, 2 Jul 2025 15:26:25 +0800 [thread overview]
Message-ID: <10d16ad5-24c5-4708-8f35-c27fd5dc6477@huawei.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FD80@smartserver.smartshare.dk>
On 2025/7/2 13:56, Morten Brørup wrote:
>> From: huangdengdui [mailto:huangdengdui@huawei.com]
>> Sent: Wednesday, 2 July 2025 04.38
>>
>> Hi everyone,
>>
>> The current rte_net_get_ptype() only supports parsing packets with a
>> single 0x8100 VLAN tag and two 0x88a8 VLAN tags,
>> but does not support processing packets with two 0x8100 VLAN tags.
>>
>> Some network cards (e.g., hns3) do support parsing packets with two
>> 0x8100 VLAN tags.
>> Can this API be extended to support such packets?
>
> It already does; the layers parameter must have RTE_PTYPE_INNER_L2_MASK set.
Yes, by setting RTE_PTYPE_INNER_L2_MASK, packets with two 0x8100 VLAN tags can be parsed,
but they will be recognized as tunnel packets even though they are not actually tunnel packets.
The current branch that parses the 0x8100 VLAN tag only handles a single VLAN tag[1][2].
Should we extend it to support parsing two or more 0x8100 VLAN tags?
[1]https://elixir.bootlin.com/dpdk/v25.07-rc2/source/lib/net/rte_net.c#L348
[2]https://elixir.bootlin.com/dpdk/v25.07-rc2/source/lib/net/rte_net.c#L500
>
>>
>> I understand that two 0x8100 VLAN tag packets aren't commonly used, so
>> I'm uncertain whether adding support is necessary.
>
> AFAIR, it's called "VLAN Stacking".
> Stacking two 0x8100 VLAN tags is commonly used.
> E.g. the majority of consumer fiber internet connections in Denmark use VLAN Stacking (not QinQ) at the network owners' Points-of-Interconnect for the service providers to identify individual homes.
Oh, I'm not very familiar with this. If stacking two 0x8100 VLAN tags is a commonly used, it would make sense for rte_net_get_ptype() to support parsing such packets.
>
>>
>> Anyone is welcome to discuss this and share their opinions.
>>
>> Thanks,
>> /Dengdui
prev parent reply other threads:[~2025-07-02 7:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 2:38 huangdengdui
2025-07-02 5:56 ` Morten Brørup
2025-07-02 7:26 ` huangdengdui [this message]
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=10d16ad5-24c5-4708-8f35-c27fd5dc6477@huawei.com \
--to=huangdengdui@huawei.com \
--cc=aman.deep.singh@intel.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=jasvinder.singh@intel.com \
--cc=lihuisong@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=mb@smartsharesystems.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).