DPDK patches and discussions
 help / color / mirror / Atom feed
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.

  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).