From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id EAEC5B62 for ; Tue, 22 Jan 2019 14:33:53 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 447E7394D40; Tue, 22 Jan 2019 13:33:53 +0000 (UTC) Received: from [172.16.255.128] (unknown [10.36.118.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 60E416013D; Tue, 22 Jan 2019 13:33:52 +0000 (UTC) From: "Eelco Chaudron" To: "Ananyev, Konstantin" Cc: dev@dpdk.org Date: Tue, 22 Jan 2019 14:33:41 +0100 Message-ID: <78E93ABD-45AA-4A04-A153-4A6C32F89AAE@redhat.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258010D905897@irsmsx105.ger.corp.intel.com> References: <9D82C157-0E57-4A7D-B8F4-DEA4ED0EA1EC@redhat.com> <28DF5BA2-09B5-468C-A575-7EEF8952E3B6@redhat.com> <2601191342CEEE43887BDE71AB977258010D905897@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Embedded-HTML: [{"HTML":[2641, 6087], "plain":[559, 2949], "uuid":"3F32947C-4F27-4C8A-A741-6C9525D07FE1"}] X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 22 Jan 2019 13:33:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN packets 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: Tue, 22 Jan 2019 13:33:54 -0000 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. 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 vf vlan > ? > Konstantin > > From: Eelco Chaudron [mailto:echaudro@redhat.com] > Sent: Thursday, January 3, 2019 4:42 PM > To: Lu, Wenzhuo ; Ananyev, Konstantin > > Cc: dev > 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