From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Ivan Malov <ivan.malov@oktetlabs.ru>,
dev@dpdk.org, Qi Z Zhang <qi.z.zhang@intel.com>,
Qiming Yang <qiming.yang@intel.com>,
Wenjun Wu <wenjun1.wu@intel.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
John McNamara <john.mcnamara@intel.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: Re: Understanding RX_OFFLOAD_VLAN_EXTEND
Date: Mon, 31 Oct 2022 20:15:08 +0000 [thread overview]
Message-ID: <97a009d2-87cf-c901-590d-7c4dad37d6ca@amd.com> (raw)
In-Reply-To: <911e37b-7c27-5bbb-ca40-4b778d396fff@oktetlabs.ru>
On 10/31/2022 6:46 PM, Ivan Malov wrote:
> Hi!
>
> We have a hard time figuring out what the API contract of
> RX_OFFLOAD_VLAN_EXTEND might be. The best educated guess
> we can make is that the feature might have something to
> do with identifying VLAN packets and extracting TCI
> without stripping the tags from incoming packets.
>
> Is this understanding correct?
>
> You see, things aren't helped by the offload bit having
> almost no commentary. Such could've shed light on its
> meaning. Perhaps this gap in documentation should
> be addressed somehow. Any opinions?
>
> Thank you.
Hi Ivan,
It is legacy from ixgbe driver, you can find more details on the ixgbe
(82599) datasheet [1].
RX_OFFLOAD_VLAN_EXTEND is *like*, QinQ but not, that is why we have
'QINQ_STRIP' offload.
And RX_OFFLOAD_VLAN_EXTEND is more a configuration option, briefly you
can ignore it.
But in detail that is to configure device in a mode that it knows that
received packets always has at least one VLAN tag, I assume it is for a
case that some in the middle networking device inserts/requires VLAN
tags. But optionally packet can have two VLAN tags. But as far as I can
see this is not for to strip the VLAN tag or to filter packet based on
it, this is just to configure device for this environment.
[1] copy/paste from a public datasheet
(http://iommu.com/datasheets/ixgbe-datasheets/82599-datasheet-v3-4.pdf),
not sure if this is up to date version, but I think it is OK for this
context:
Double VLAN and Single VLAN Support
The 82599 supports a mode where all received and sent packets have at
least one VLAN tag in addition to the regular tagging that might
optionally be added. In this document, when a packet carries two VLAN
headers, the first header is referred to as an outer VLAN and the second
header as an inner VLAN header (as listed in the table that follows).
This mode is used for systems where the near end switch adds the outer
VLAN header containing switching information. This mode is enabled by
the following configuration:
• This mode is activated by setting the DMATXCTL.GDV and the Extended
VLAN bit in the CTRL_EXT register.
• The EtherType of the VLAN tag used for the additional VLAN is defined
in the VET EXT field in the EXVET register.
next prev parent reply other threads:[~2022-10-31 20:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 18:46 Ivan Malov
2022-10-31 20:15 ` Ferruh Yigit [this message]
2022-10-31 21:56 ` Ivan Malov
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=97a009d2-87cf-c901-590d-7c4dad37d6ca@amd.com \
--to=ferruh.yigit@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ivan.malov@oktetlabs.ru \
--cc=jerinj@marvell.com \
--cc=john.mcnamara@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=qiming.yang@intel.com \
--cc=thomas@monjalon.net \
--cc=wenjun1.wu@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).