From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 2049C58FA for ; Mon, 3 Sep 2018 13:45:54 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Sep 2018 04:45:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,324,1531810800"; d="scan'208";a="68002506" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga008.fm.intel.com with ESMTP; 03 Sep 2018 04:45:32 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 3 Sep 2018 04:45:32 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 3 Sep 2018 04:45:31 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.150]) with mapi id 14.03.0319.002; Mon, 3 Sep 2018 19:45:30 +0800 From: "Zhang, Qi Z" To: "robertshearman@gmail.com" , "dev@dpdk.org" CC: "Lu, Wenzhuo" , "Ananyev, Konstantin" , Robert Shearman Thread-Topic: [dpdk-dev] [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs in VF Thread-Index: AQHUO8oHnI46MI+P9kK05FN68G+8nKTeYCIw Date: Mon, 3 Sep 2018 11:45:30 +0000 Message-ID: <039ED4275CED7440929022BC67E706115327F501@SHSMSX103.ccr.corp.intel.com> References: <1535128501-31597-1-git-send-email-robertshearman@gmail.com> In-Reply-To: <1535128501-31597-1-git-send-email-robertshearman@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTgwNmVhZDktZjkwZS00ZjhjLWEyMGQtZTRmYzgzZWIxZmQ0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNTZISVJSXC93QUc5aGlJVzU2YXlVSVhISWFVeTRzK1VabnlvUUU2VmU5d1d5ak80SUc0RHFlNVV1d2xCdktHbXMifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs in VF X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 11:45:55 -0000 Hi Robert: > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of > robertshearman@gmail.com > Sent: Saturday, August 25, 2018 12:35 AM > To: dev@dpdk.org > Cc: Lu, Wenzhuo ; Ananyev, Konstantin > ; Robert Shearman > > Subject: [dpdk-dev] [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs in = VF >=20 > From: Robert Shearman >=20 > SR-IOV VFs support "transparent" VLANs. Traffic from/to a VM associated w= ith > a VF has a VLAN tag inserted/stripped in a manner intended to be totally > transparent to the VM. On a Linux hypervisor the vlan can be specified b= y "ip > link set vf vlan ". > The VM VF driver is not configured to use any VLAN and the VM should neve= r > see the transparent VLAN for that reason. However, in practice these VLA= N > headers are being received by the VM which discards the packets as that V= LAN > is unknown to it. The Linux kernel ixbge driver explicitly removes the V= LAN in > this case (presumably due to the hardware not being able to do this) but = the > DPDK driver does not. I'm not quite understand this part. What does explicitly remove the VLAN means?,=20 DPDK also discard unmatched VLAN and strip vlan if vlan_strip is enabled wh= at is the gap? It will be better if you can give same examples >=20 > This patch mirrors the kernel driver behaviour by removing the VLAN on th= e VF > side. This is done by checking the VLAN in the VFTA, where the hypervisor= will > have set the bit in the VFTA corresponding to the VLAN if transparent VLA= Ns > were being used for the VF. If the VLAN is set in the VFTA then it is kno= wn that > it's a transparent VLAN case and so the VLAN is stripped from the mbuf.=20 This is missing leading. >>From your code, I only saw vlan flag in ol_flag is stripped, but not VLAN i= s stripped. I think vlan is always be stripped if we enable vlan strip on queue. > To > limit any potential performance impact on the PF data path, the RX path i= s split > into PF and VF versions with the transparent VLAN stripping only done in = the > VF path. Measurements with our application show ~2% performance hit for > the VF case and none for the PF case. >=20 ... > +/* > + * Filter out unknown vlans resulting from use of transparent vlan. > + * > + * When a VF is configured to use transparent vlans then the VF can > + * see this VLAN being set in the packet, meaning that the transparent > + * property isn't preserved. Furthermore, when the VF is used in a > + * guest VM then there's no way of knowing for sure that transparent > + * VLAN is in use and what tag value has been configured. So work > + * around this by removing the VLAN flag if the VF isn't interested in > + * the VLAN tag. > + */ > +static inline void > +ixgbevf_trans_vlan_sw_filter_hdr(struct rte_mbuf *m, > + const struct ixgbe_vfta *vfta) > +{ > + if (m->ol_flags & PKT_RX_VLAN) { > + uint16_t vlan =3D m->vlan_tci & 0xFFF; > + > + if (!ixgbe_vfta_is_vlan_set(vfta, vlan)) > + m->ol_flags &=3D ~PKT_RX_VLAN; > + } > +} > + Ideally all driver's behavior should be consistent with the same configure. if "transparent vlan" looks like a general feature, it may not only bind to= VF or even just ixgbevf. (what about i40evf?) Otherwise, it should be handled in application , but not the driver. ... > + ixgbe_unknown_vlan_sw_filter_hdr(rx_pkts[pos + 3], vfta, rxq); Where is ixgbe_unknown_vlan_sw_filter_hdr be defined? I saw it is only be u= sed in ixgbe_rxtx_vec_neon.c, so assume there will be a compile error on th= at platform? Regards Qi