From patchwork Wed Oct 11 13:19:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Iain Barker X-Patchwork-Id: 30121 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E3DFA1B19D; Wed, 11 Oct 2017 15:19:45 +0200 (CEST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by dpdk.org (Postfix) with ESMTP id 6CAE71B161; Wed, 11 Oct 2017 15:19:44 +0200 (CEST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9BDJgc6013296 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Oct 2017 13:19:43 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v9BDJgte021195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Oct 2017 13:19:42 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9BDJf8x006339; Wed, 11 Oct 2017 13:19:42 GMT MIME-Version: 1.0 Message-ID: <93359c04-0da3-4f3c-ba56-799817775781@default> Date: Wed, 11 Oct 2017 06:19:41 -0700 (PDT) From: Iain Barker To: users@dpdk.org Cc: dev@dpdk.org References: <6a275bea-214e-489b-ba42-df70328b3854@default> In-Reply-To: <6a275bea-214e-489b-ba42-df70328b3854@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 15.0.4963.0 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] Subject: Re: [dpdk-dev] [dpdk-users] VLAN tags always stripped on i40evf [VMware SR-IOV] 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tuesday, October 10, 2017 9:49 AM (EST), Iain Barker wrote: > I have a problem trying to get VLAN tagged frames to be received at the i40evf PMD. With more debugging enabled, I can see that this seems to be a compatibility problem between DPDK and i40evf related to VLAN hardware stripping. Specifically, when DPDK requests VLAN stripping to be disabled by VF, but the PF policy doesn't allow it to be disabled (as is the case for VMware SR-IOV), an error is returned from the API. testpmd> vlan set strip off 0 i40evf_execute_vf_cmd(): No response for 28 i40evf_disable_vlan_strip(): Failed to execute command of VIRTCHNL_OP_DISABLE_VLAN_STRIPPING In that case, received frames with VLAN headers will still be stripped at the PF, and the TCI will record the missing VLAN details when handed up to the DPDK driver. With i40e debug enabled, it's clear to see the difference being reported in i40e_rxd_to_vlan_tci: Example using VLAN on i40e PCI (vlan works): PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 0, vlan_tci_outer: 0 Port 0 pkt-len=102 nb-segs=1 ETH: src=00:10:E0:8D:A7:52 dst=00:10:E0:8A:86:8A [vlan id=8] type=0x0800 IPV4: src=8.8.8.102 dst=8.8.8.3 proto=1 (ICMP) ICMP: echo request seq id=1 Example using VLAN on i40evf SR-IOV (vlan fails): PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 8, vlan_tci_outer: 0 Port 0 pkt-len=60 nb-segs=1 ETH: src=00:10:E0:8D:A7:52 dst=FF:FF:FF:FF:FF:FF type=0x0806 ARP: hrd=1 proto=0x0800 hln=6 pln=4 op=1 (ARP Request) sha=00:10:E0:8D:A7:52 sip=8.8.8.102 tha=00:00:00:00:00:00 tip=8.8.8.3 As the application requested tagging not be stripped, and the hardware driver was not able to disable strip, in my opinion DPDK should emulate the requested behavior by re-add the missing VLAN header in the RX thread, before it passes the mbuf to the application. I'm guessing that the native Linux driver is smart enough to do something like this automatically in software, but DPDK does not... Adding a call to rte_vlan_insert() to reinstate the VLAN header using the data from TCI is sufficient to avoid the problem in a quick test. For a proper solution, this would need to be made selective based on whether the port config originally asked for VLANs to be stripped or not. But I'm not sure that rte_vlan_insert() has enough context to be able to access that data, as it's stored in the driver/hw struct not the rx buffer. Obviously the same would be required in the vector rxtx and similar data paths for other drivers, if affected by the same shortcoming. I don't have other combinations available that I could test with, and I guess VMware i40evf SR-IOV VLAN isn't part of the DPDK release test suite either. cc: dev@dpdk.org for comment as this is getting beyond my level of knowledge as a DPDK user thanks, Iain --- drivers/net/i40e/i40e_rxtx.c.orig 2016-11-30 04:28:48.000000000 -0500 +++ drivers/net/i40e/i40e_rxtx.c 2017-10-10 15:07:10.851398087 -0400 @@ -93,6 +93,8 @@ rte_le_to_cpu_16(rxdp->wb.qword0.lo_dword.l2tag1); PMD_RX_LOG(DEBUG, "Descriptor l2tag1: %u", rte_le_to_cpu_16(rxdp->wb.qword0.lo_dword.l2tag1)); + // vlan got stripped. Re-inject vlan from tci + rte_vlan_insert(&mb); } else { mb->vlan_tci = 0; }