From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"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>
Subject: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload
Date: Fri, 26 Oct 2018 10:56:15 +0000 [thread overview]
Message-ID: <20181026105559.GA6843@jerin> (raw)
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
next reply other threads:[~2018-10-26 10:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-26 10:56 Jerin Jacob [this message]
2018-10-26 13:40 ` Ferruh Yigit
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=20181026105559.GA6843@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=arybchenko@solarflare.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=olivier.matz@6wind.com \
--cc=qi.z.zhang@intel.com \
--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).