From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: DEV_RX_OFFLOAD_VLAN_EXTEND offload Date: Fri, 26 Oct 2018 14:35:24 +0000 Message-ID: <20181026143508.GA2616@jerin> References: <20181026105559.GA6843@jerin> <1888b918-6871-eadc-6aa1-fbf6b0cf48fe@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "thomas@monjalon.net" , "arybchenko@solarflare.com" , "olivier.matz@6wind.com" , "qi.z.zhang@intel.com" , "beilei.xing@intel.com" , Wenzhuo Lu , Konstantin Ananyev To: Ferruh Yigit Return-path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0074.outbound.protection.outlook.com [104.47.34.74]) by dpdk.org (Postfix) with ESMTP id C0AC54C99 for ; Fri, 26 Oct 2018 16:38:35 +0200 (CEST) In-Reply-To: <1888b918-6871-eadc-6aa1-fbf6b0cf48fe@intel.com> Content-Language: en-US Content-ID: <27B63B301156464BAD0CB4BE3537F64F@namprd07.prod.outlook.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Fri, 26 Oct 2018 14:40:42 +0100 > From: Ferruh Yigit > To: Jerin Jacob , "dev@dpdk.org" > > CC: "thomas@monjalon.net" , > "arybchenko@solarflare.com" , > "olivier.matz@6wind.com" , "qi.z.zhang@intel.com= " > , "beilei.xing@intel.com" , > Wenzhuo Lu , Konstantin Ananyev > > Subject: Re: [dpdk-dev] DEV_RX_OFFLOAD_VLAN_EXTEND offload > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.9.1 >=20 >=20 > 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 VLA= N > > 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 i= s > > 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 change= d > > 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 > > >=20 > This looks similar to QinQ but it seems not, in ixgbe datasheet it has: Yes. QinQ there is an already an offload called DEV_RX_OFFLOAD_QINQ_STRIP >=20 > " > Double VLAN and Single VLAN Support > ----------------------------------- > <....> > This mode is used for systems where the near end switch adds the outer V= LAN > header containing switching information. > <...> > " >=20 > 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.