Hi, Konstantin > -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, > Konstantin > Sent: Wednesday, January 23, 2019 10:09 PM > To: Eelco Chaudron <echau...@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:echau...@redhat.com] > > Sent: Thursday, January 3, 2019 4:42 PM > > To: Lu, Wenzhuo <wenzhuo...@intel.com>; Ananyev, Konstantin > > <konstantin.anan...@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
