From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id AE9E3231E for ; Tue, 4 Sep 2018 11:57:41 +0200 (CEST) Received: by mail-wr1-f67.google.com with SMTP id a108-v6so3228905wrc.13 for ; Tue, 04 Sep 2018 02:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=euyo10eNYW5Dc/oQf/gj7uZU04pIQwA+aPGxGa320MQ=; b=Ew1Z1PG6GfUPG2en/d5k+0f2D29FOFYouS46fRexpw9c20gpBupBGTX/zR9W8OzUBJ sCU4blsxdYLIIgcpCBDWUzFaaQZ0bnEzGjgBAfokmOYI4+5h3YQkprImlNYDPYexWbes SOCUHzYlohzWF3lMe4B0m5qnaf0gyFKbL4AZ6WKA9exo7uqIrgOpe5izS5PCZSLKVsVU KevDiSQSoDE04/0Se0jZxwW8f58Oz9aJ/KOJI6jFtSiwXt2KQBEYXlACukgfdfEBDGnu NPZUkNW51bJVXZ4+ZVkoUoix0Odrtu4MHXI/YtRDlRHbAlrgrjJ63l5Eokwy5wAVVBI9 vxsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=euyo10eNYW5Dc/oQf/gj7uZU04pIQwA+aPGxGa320MQ=; b=QkfPk+Y/ykSi/AI6rKkhYbF3ImkfMBGRrzDzBXmo826h9kVeIvfxcpJdLc4ywGERaI fgxoQQVDqZrLSK6i8wsl1gxgOvPywFc5/2La1WrM6aYIQBsRlWlEqS8d8N/1T8Y92j6D O1I2pBt/Yt4jHNB+HyEIEZva0oVHw6rwIUyKA/2BbjlGx2sev2OqgQx9D59X+zJdCBO9 ACKYnicikNYr8MmfaLddDwcG8SmAglg7dTujFfsRZN4ruuK83TbT4rjZAd4wfLlPYWxT ZYgvCfsPEnlYzENoS6M+XdBJ/I16ONjRmi3ktOA9yhsgSu+s0cK+fBKjt/OtPNOcMtCq AcOQ== X-Gm-Message-State: APzg51ADfsyv31rW2gfXv3VtjHAjR8hQfPYG8fAeTIThLsGPLJ8c4Mwy eCGSNOgLzmDCdbK3gkYhGx0Ja4cGI5s= X-Google-Smtp-Source: ANB0VdYddm3ugWphx89WjQaf5xC8XPvDYIkTWBh6Dw+lax9LNmumozkED9leD7b7QaMgUH+emmmEWA== X-Received: by 2002:a5d:54cb:: with SMTP id x11-v6mr5810125wrv.150.1536055061375; Tue, 04 Sep 2018 02:57:41 -0700 (PDT) Received: from [10.156.47.67] ([137.221.143.78]) by smtp.gmail.com with ESMTPSA id l10-v6sm21007494wre.0.2018.09.04.02.57.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 02:57:40 -0700 (PDT) To: "Zhang, Qi Z" , "dev@dpdk.org" Cc: "Lu, Wenzhuo" , "Ananyev, Konstantin" , Robert Shearman References: <1535128501-31597-1-git-send-email-robertshearman@gmail.com> <039ED4275CED7440929022BC67E706115327F501@SHSMSX103.ccr.corp.intel.com> <0ee303e8-0d63-eafb-ec77-b9e447183a76@gmail.com> <039ED4275CED7440929022BC67E706115327F96F@SHSMSX103.ccr.corp.intel.com> From: Robert Shearman Message-ID: Date: Tue, 4 Sep 2018 10:57:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <039ED4275CED7440929022BC67E706115327F96F@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs in VF 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, 04 Sep 2018 09:57:42 -0000 Hi Qi, On 04/09/2018 03:16, Zhang, Qi Z wrote: >> -----Original Message----- >> From: Robert Shearman [mailto:robertshearman@gmail.com] >> Sent: Monday, September 3, 2018 9:14 PM >> To: Zhang, Qi Z ; dev@dpdk.org >> Cc: Lu, Wenzhuo ; Ananyev, Konstantin >> ; Robert Shearman >> >> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs in >> VF >> >> Hi Qi, >> >> On 03/09/2018 12:45, Zhang, Qi Z wrote: >>> Hi Robert: >>> >>>> -----Original Message----- >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of >>>> robertshearman@gmail.com >>>> Sent: Saturday, August 25, 2018 12:35 AM >>>> To: dev@dpdk.org >>>> Cc: Lu, Wenzhuo ; Ananyev, Konstantin >>>> ; Robert Shearman >>>> >>>> Subject: [dpdk-dev] [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs >>>> in VF >>>> >>>> From: Robert Shearman >>>> >>>> SR-IOV VFs support "transparent" VLANs. Traffic from/to a VM >>>> associated with a VF has a VLAN tag inserted/stripped in a manner >>>> intended to be totally transparent to the VM. On a Linux hypervisor >>>> the vlan can be specified by "ip link set vf vlan ". >>>> The VM VF driver is not configured to use any VLAN and the VM should >>>> never see the transparent VLAN for that reason. However, in practice >>>> these VLAN headers are being received by the VM which discards the >>>> packets as that VLAN is unknown to it. The Linux kernel ixbge driver >>>> explicitly removes the VLAN in this case (presumably due to the >>>> hardware not being able to do this) but the DPDK driver does not. >>> >>> I'm not quite understand this part. >>> What does explicitly remove the VLAN means?, DPDK also discard >>> unmatched VLAN and strip vlan if vlan_strip is enabled what is the gap? >>> It will be better if you can give same examples >> >> Sure. Typical use case for this is a hypervisor where it is necessary to provide >> L2 access into the guests, but there are insufficient, and so the hypervisor is >> using the PF and VFs are assigned to guests. In order to avoid having to >> configure each guest to use the VLAN and to not send any untagged traffic it is >> desirable to use transparent VLANs. For example: >> Guest 1 = VLAN 10 >> Guest 2 = VLAN 20 >> >> ip link set eth0 vf 1 vlan 10 >> ip link set eth0 vf 2 vlan 20 >> >> Now this means that packets arriving tagged on the physical port should be >> delivered to the guest and arrive in the guest untagged. Similarly, packets >> transmitted untagged by the guest should gain a tag before they go out of the >> physical port. What you get when using the Linux VF ixgbe driver inside the >> VMs is exactly this since the driver knows that for this hardware the >> transparent stripping isn't done in hardware and is done inside the driver. >> What you get currently when using the DPDK VF ixgbe driver inside the VMs is >> that packets arrive tagged (e.g. with VLAN tag 10) and these are then dropped >> because the VM doesn't know about VLAN 10. >> >> Transparent VLAN insertion works currently with both Linux and DPDK VF >> drivers. > > What do you mean "stripping isn't done in hardware" and "packets arrived tagged"? > Let me explain how PMD driver works. (or it is expected) > if we enable vlan_strip, the VLAN header is expected to be stripped from packet data by hardware. > And in rx descriptor, it still keep the stripped vlan information, so driver will set mbuf->ol_flags with PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED and also set stripped vlan tag to mbuf->vlan_tci > So in my review, it is "stripping is done and packets arrived with untagged", and application also know what exactly happened and make decision based on the requirement > > So do you mean ixgbevf does not support vlan_strip as a hardware offload?, and it should be done with software? > But in your code, I didn't see the part that vlan header is stripped from the packet data. ( set mbuf->ol_flag and mbuf->vlan_tci does not mean the vlan is stripped) I understand how the VLAN stripping hardware offload is supposed to work, but this use case is distinct from VLAN stripping and it was my mistake to use that loaded term in my explanation of the use case. The expectation in this case is that the packet arrive completely untagged, i.e. whether the VLAN has been stripped and placed in metadata or not. The application running inside the VM expects the packet to arrive is if the VLAN tag was never there. The application cannot do the removal of the VLAN tag itself because in this use case it is implicit that it shouldn't know about the tag and the presence of the tag is driver/hardware specific. Thanks for highlighting the PKT_RX_VLAN_STRIPPED flag - I should remove that as well when the transparent VLAN filter triggers. Thanks, Rob