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 E247A1B3A7 for ; Thu, 3 Jan 2019 17:42:30 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 34E307FD4B; Thu, 3 Jan 2019 16:42:30 +0000 (UTC) Received: from [10.36.116.226] (ovpn-116-226.ams2.redhat.com [10.36.116.226]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 587DC6091D; Thu, 3 Jan 2019 16:42:29 +0000 (UTC) From: "Eelco Chaudron" To: wenzhuo.lu@intel.com, konstantin.ananyev@intel.com Cc: dev Date: Thu, 03 Jan 2019 17:42:27 +0100 Message-ID: <28DF5BA2-09B5-468C-A575-7EEF8952E3B6@redhat.com> In-Reply-To: <9D82C157-0E57-4A7D-B8F4-DEA4ED0EA1EC@redhat.com> References: <9D82C157-0E57-4A7D-B8F4-DEA4ED0EA1EC@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 03 Jan 2019 16:42:30 +0000 (UTC) Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown 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: Thu, 03 Jan 2019 16:42:31 -0000 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