> -----Original Message----- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Monday, December 14, 2015 7:25 PM > To: Ananyev, Konstantin > Cc: Zhang, Helin; dev at dpdk.org; Tom Kiely > Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. > > On Mon, 14 Dec 2015 19:12:26 +0000 > "Ananyev, Konstantin" <konstantin.ananyev at intel.com> wrote: > > > > > > > > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > > Sent: Friday, December 11, 2015 4:59 PM > > > To: Zhang, Helin; Ananyev, Konstantin > > > Cc: dev at dpdk.org; Tom Kiely; Stephen Hemminger > > > Subject: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. > > > > > > From: Tom Kiely <tkiely at brocade.com> > > > > > > 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 <device> vf <n> vlan <v>". > > > 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 like 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 information > > for the RX packet. > > Though the patch actually clears VLAN info only for the RX packet whose > > 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 information > > would be preserved with and without the patch. > > > > If you need to clear VLAN information, why not to do it on the upper layer > > - inside your application itself? > > Either create some sort of wrapper around rx_burst(), or setup an RX > > 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 > ixgbevf_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 the 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. > > The other option is have a copy of all the receive logic which is only > 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 > > Tom has more details. But you can reproduce problem by just testing current > code with the transparent VLAN option. > >
