DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"qi.z.zhang@intel.com" <qi.z.zhang@intel.com>,
	"beilei.xing@intel.com" <beilei.xing@intel.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>
Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
Date: Fri, 26 Oct 2018 14:40:42 +0100	[thread overview]
Message-ID: <1888b918-6871-eadc-6aa1-fbf6b0cf48fe@intel.com> (raw)
In-Reply-To: <20181026105559.GA6843@jerin>

On 10/26/2018 11:56 AM, Jerin Jacob wrote:
> 
> Does anyone know the expectation of DEV_RX_OFFLOAD_VLAN_EXTEND
> offload? Does not look like it is documented.
> 
> Looks like it is very specific to Intel controllers, Based on 82599 HRM,
> it is following, not sure what is the real expectation from NIC in
> normative terms.
> 
> Extended VLAN.
> -------------
> When set, all incoming Rx packets are expected to have at least one VLAN
> with the Ether type as defined in EXVET register. The packets can have
> an inner-VLAN that should be used for all filtering purposes. All Tx
> packets are expected to have at least one VLAN added to them by the
> host. In the case of an additional VLAN request (VLE), the inner-VLAN is
> added by the hardware after the outer-VLAN is added by the host.
> This bit should only be reset by a PCIe reset and should only be changed
> while Tx and Rx processes are stopped.
> The exception to this rule are MAC control packets such as flow control,
> 802.1x, LACP, etc. that never carry a VLAN tag of any type
> 

This looks similar to QinQ but it seems not, in ixgbe datasheet it has:

"
Double VLAN and Single VLAN Support
-----------------------------------
<....>
 This mode is used for systems where the near end switch adds the outer VLAN
header containing switching information.
<...>
"

And it in this mode hw doesn't insert or strip the outer VLAN, it expect SW does
it. The ethernet type is not 0x88A8 but can be anything set on EXVET.VET_EXT. So
looks like it is to let switch to add custom VLAN tags and NIC to ignore them.

  reply	other threads:[~2018-10-26 13:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26 10:56 Jerin Jacob
2018-10-26 13:40 ` Ferruh Yigit [this message]
2018-10-26 14:35   ` Jerin Jacob
2018-11-01  9:50     ` Zhao1, Wei
2018-11-01 10:34       ` Jerin Jacob
2018-11-05  4:22         ` Zhao1, Wei
2018-11-05  6:55           ` Thomas Monjalon
2018-11-05  9:09         ` Zhao1, Wei

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=1888b918-6871-eadc-6aa1-fbf6b0cf48fe@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=qi.z.zhang@intel.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@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).