Re: [dpdk-dev] VF of a X520 card does not process VLAN packets

["Zhao1, Wei" <wei.zhao1@intel.com>]

Hi, Konstantin

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Wednesday, January 23, 2019 10:09 PM
> To: Eelco Chaudron <echaudro@redhat.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
> 
> Hi Eelco,
> 
> >
> >
> > Hi Konstantin,
> > Thanks for your reply…
> > Yes adding the VLAN to the VF from the kernel side will work, however,
> this is a different behaviour than the XL710.
> > The XL710 will allow all VLANs to pass through once the PMD takes control
> of the VF.


> 
> It is not about who controls VF.
> On ixgbe VLAN filter are configured and controlled by PF.
> In your case PF is controlled by kernel ixgbe driver.
> AFAIK, in SRIOV mode ixgbe kernel driver always enables VLAN filtering, and
> there is not possible to revert it (at least I don't know how).
> Konstantin

Yes, you are right. BY now, ixgbe vf has no ops to enable this.
I have commit a patch set to enable VF VLAN and MAC promiscuous on ixgbe.
And also dpdk pf host has update to pf kernel 5.3.7 which has support this.

https://patches.dpdk.org/patch/49870/ 

https://patches.dpdk.org/patch/49871/ 

https://patches.dpdk.org/patch/49872/


> 
> > The real use case is using this VF interface trough Open vSwitch which
> needs to see all packets regardless of the VLAN.
> > It does not make sense to create 4K VLANs through the kernel to get this
> working.
> > Looking forward to your reply…
> > Cheers,
> > Eelco
> >
> > On 18 Jan 2019, at 12:25, Ananyev, Konstantin wrote:
> > Hi
> > It’s been while since I looked at it last time, but shouldn’t you
> > assign desired vlan tag to the VF first:
> > ip link set <device> vf <num> vlan <num> ?
> > Konstantin
> >
> > From: Eelco Chaudron [mailto:echaudro@redhat.com]
> > Sent: Thursday, January 3, 2019 4:42 PM
> > To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>
> > Cc: dev <dev@dpdk.org>
> > Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN
> > packets
> >
> > Hi maintainers, any feedback on the below?
> > Thanks,
> > Eelco
> > On 18 Dec 2018, at 12:06, Eelco Chaudron wrote:
> > Hi,
> > I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not
> > accepting tagged VLAN packets (it does accept tag 0). Is this a known
> bug/limitation of the 82599ES chipset?
> > This is how I've tested it:
> > $ echo 1 > /sys/bus/pci/devices/0000:05:00.0/sriov_numvfs
> > $driverctl -v set-override 0000:05:10.0 vfio-pci $./testpmd -c 7 -n 4
> > --socket-mem 2048,0 -w 0000:05:10.0 -- \ --burst 64 -i --rxq=1 --txq=1
> > --rxd=4096 --txd=1024 \
> > —coremask=6 --auto-start --port-topology=chained
> > EAL: Detected 28 lcore(s)
> > EAL: Detected 1 NUMA nodes
> > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket ...
> > testpmd>
> > I’m sending broadcast ARP packets:
> > Ethernet II, Src: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00), Dst:
> > ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> > Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> > Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) .... ..1. .... ....
> > .... .... = LG bit: Locally administered address (this is NOT the
> > factory default) .... ...1 .... .... .... .... = IG bit: Group address
> > (multicast/broadcast)
> > Source: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
> > Address: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00) .... ..0. .... ....
> > .... .... = LG bit: Globally unique address (factory default) ....
> > ...0 .... .... .... .... = IG bit: Individual address (unicast)
> > Type: 802.1Q Virtual LAN (0x8100)
> > 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10 000. .... .... .... =
> > Priority: Best Effort (default) (0)
> > ...0 .... .... .... = CFI: Canonical (0) .... 0000 0000 1010 = ID: 10
> > Type: ARP (0x0806)
> > Padding: 2e2f303132333435363738393a3b
> > Trailer: 3c3d3e3f404142434445464748494a4b4c4d4e4f50515253...
> > Address Resolution Protocol (request/gratuitous ARP) Hardware type:
> > Ethernet (1) Protocol type: IP (0x0800) Hardware size: 6 Protocol
> > size: 4
> > Opcode: request (1)
> > [Is gratuitous: True]
> > Sender MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00) Sender IP
> > address: 0.0.0.0 (0.0.0.0) Target MAC address: 00:00:00:00:00:00
> > (00:00:00:00:00:00) Target IP address: 0.0.0.0 (0.0.0.0) No traffic is
> > received, if you replace tag 10 with 0, packets are received.
> > Note that this is a simple reproducer with testpmd, but it's reported
> > as part of an OVS integration. This works fine on the physical port, or with a
> VF on an XL710 card.
> > Any input appreciated.
> > Thanks,
> > Eelco