From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 9D2DAE72 for ; Tue, 15 Dec 2015 15:37:08 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 15 Dec 2015 06:37:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,432,1444719600"; d="scan'208";a="874087662" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 15 Dec 2015 06:37:06 -0800 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Dec 2015 14:37:05 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.203]) by irsmsx112.ger.corp.intel.com ([169.254.1.8]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 14:37:05 +0000 From: "Ananyev, Konstantin" To: Stephen Hemminger Thread-Topic: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. Thread-Index: AQHRNDVIPc2v9xXs5Ua8nTZmK+JUAZ7K2GuwgAAJfACAAAQKkIAAIEQAgAEarJA= Date: Tue, 15 Dec 2015 14:37:04 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836AD3DA2@irsmsx105.ger.corp.intel.com> References: <1449853163-25673-1-git-send-email-stephen@networkplumber.org> <2601191342CEEE43887BDE71AB97725836AD3A0B@irsmsx105.ger.corp.intel.com> <20151214112516.35bbc1f8@xeon-e3> <2601191342CEEE43887BDE71AB97725836AD3A5C@irsmsx105.ger.corp.intel.com> <20151214133512.48593b49@xeon-e3> In-Reply-To: <20151214133512.48593b49@xeon-e3> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 14:37:09 -0000 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Monday, December 14, 2015 9:35 PM > To: Ananyev, Konstantin > Cc: Zhang, Helin; dev@dpdk.org; Tom Kiely > Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers= . >=20 > On Mon, 14 Dec 2015 19:57:10 +0000 > "Ananyev, Konstantin" wrote: >=20 > > > > > > > -----Original Message----- > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > > Sent: Monday, December 14, 2015 7:25 PM > > > To: Ananyev, Konstantin > > > Cc: Zhang, Helin; dev@dpdk.org; Tom Kiely > > > Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet hea= ders. > > > > > > On Mon, 14 Dec 2015 19:12:26 +0000 > > > "Ananyev, Konstantin" wrote: > > > > > > > > > > > > > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > > > > Sent: Friday, December 11, 2015 4:59 PM > > > > > To: Zhang, Helin; Ananyev, Konstantin > > > > > Cc: dev@dpdk.org; Tom Kiely; Stephen Hemminger > > > > > Subject: [PATCH] ixgbe: Discard SRIOV transparent vlan packet hea= ders. > > > > > > > > > > From: Tom Kiely > > > > > > > > > > SRIOV VFs support "transparent" vlans. Traffic from/to a VM > > > > > associated with a VF is tagged/untagged with the specified > > > > > vlan in a manner intended to be totally transparent to the VM. > > > > > > > > > > The vlan is specified by "ip link set vf vlan ". > > > > > The VM is not configured for any vlan on the VF and the VM > > > > > should never see these transparent vlan headers for that reason. > > > > > > > > > > However, in practice these vlan headers are being received by > > > > > the VM which discards the packets as that vlan is unknown to it. > > > > > The Linux kernel explicitly discards such vlan headers but DPDK > > > > > does not. > > > > > This patch mirrors the kernel behaviour for SRIOV VFs only > > > > > > > > > > > > I have few concerns about that approach: > > > > > > > > 1. I don't think vlan_tci info should *always* be stripped by vf RX= routine. > > > > There could be configurations when that information might be needed= by upper layer. > > > > Let say VF can be member of 2 or more VLANs and upper layer would l= ike to have that information > > > > for further processing. > > > > Or special mirror VF, that does traffic snnoping, or something else= . > > > > 2. Proposed implementation would introduce a slowdown for all VF RX= routines. > > > > 3. From the description it seems like the aim is to clear VLAN info= rmation for the RX packet. > > > > Though the patch actually clears VLAN info only for the RX packet w= hose VLAN tag is not present inside SW copy of VFTA table. > > > > Which makes no much point to me: > > > > If VLAN is not present in HW VFTA table, then packet with that VLAN= tag will be discarded by HW anyway. > > > > If it is present inside VFTA table (both SW & HW), then VLAN inform= ation would be preserved with and without the patch. > > > > > > > > If you need to clear VLAN information, why not to do it on the uppe= r layer - inside your application itself? > > > > Either create some sort of wrapper around rx_burst(), or setup an R= X call-back for your VF device. > > > > > > > > Konstantin > > > > > > > > > The aim is to get SRIOV to work when the transparent VLAN tag feature= is used. > > > Please talk to the Linux driver team. Similar code exists there in ix= gbevf_process_skb_fields. > > > > > > Ah ok, I realised what you are trying to achieve now: > > You setup HW VFTA[] from the PF, so from VF point of view SW copy of th= e VFTA[] remains unset. > > So HW will pass VLAN packet in, but then SW will clear VLAN tag. > > Ok, that clears #3 above, but I think #1,2 still remain. >=20 > On the host, what configured is a vlan tag per VF per guest >=20 > Tom had more info in the original mail. >=20 > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/28932 >=20 > > > > > > The other option is have a copy of all the receive logic which is onl= y > > > used by VF code. > > > > Why that's the only option? > > Why can't you clear that VLAN information above the PMD layer? > > Keep/obtain a copy of VFTA[] somewhere on the upper layer, > > and do actual clear after rx_burst() returns? > > Konstantin >=20 > The problem is that the guest is supposed to not see the VLAN tags (it ha= s no reason to), > but the hardware leaves a VLAN tag on there. Yes, I understand what you are trying to achieve. What I am trying to say: 1. VLAN tag removing shouldn't be forced for all VFs. I think there are scenarios where existing behaviour (keeping vlan_tci and = ol_flags intact) are what people need. One example would be mirror VF doing other VFs traffic snooping. Probably some other cases too. 2. The way you implemented it - it might cause a RX performance degradation= (specially for VF). That's why I think it better to be implemented on top of PMD: i.e: some sort of wrapper that checks all packets returned by rx_burst() an= d clears vlan_tci if needed.=20 That would give you desired behaviour and keep current implementation intac= t. Konstantin =20