From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com [209.85.192.169]) by dpdk.org (Postfix) with ESMTP id 2264B37A6 for ; Mon, 14 Dec 2015 22:35:51 +0100 (CET) Received: by pfbo64 with SMTP id o64so33297607pfb.1 for ; Mon, 14 Dec 2015 13:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=uyns5fKZLXPdpJIw/MC+LzbVGdSpB3JZPv4PoFz64yE=; b=wQ4QC3KAqfVgBZe+JeW7mnDjKUdISFZ3YRoJCKvpRTD3YXMYDuHGl3iVrTjxQcxZDv qQnyIR8VksdK7b4Xd6RUDN84ilv5qA+Z29JZ7NuPaHVtj0haR8NX665lkFQc6jNLXpts lPY3gwr058lOBKObCnf51nioh6AMhqKZJYTDcephbjfDNMfYYosXXPnO4XAnsheW4l2q oD3bYB6XPvqerncvOjJlb4pOeRXx8Rbn5q5xPbgSlEKSmQi8CPTbqPjARTYIWQ4JaEG0 JSEj2B3UY6Kd37F+u4hSgDEMSBZbkMatncTy80qqlEIvjJ9pdjRIu5I9vuohOwUcwNlv 7I1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=uyns5fKZLXPdpJIw/MC+LzbVGdSpB3JZPv4PoFz64yE=; b=IeMg7wzJ8wJbXcLjC1ti77KB1EseOmujN+d713YuLZJINvoh6hV0DPCRpX5kDm1Lvk zbbZu4sDZOzk2yTd2ba9EZWAZFka78+MmI960Vq4D5OnqpAAEIedZu3sk7ScS/TWbdUz nXVTrhduFHPh3nPc7ncu5Wb9dThWiCceFRhPqahL6uWudoNgvF3wfCudf5cgXAW4IXUC WDu15mRW4gAa33OJU1gaQJV5aYb6CHAnYk7e+G4o07qbpUnkp//RBSe5JNItQGHYue+v SzuIj4dey7aUqBuGJ9/uTnpFD/+1z/e9WxoEU8IdsiU6Vs0DVSfFI5M/QA6VEOQl7iQO 7lmQ== X-Gm-Message-State: ALoCoQkaPVyBNFJpSJBK7RX3CrukdT2z1CaNgn+LhPR9eKkzvJ1TUaxPUXXv1qA7TcGFJOo3pYjR6tI0HWffG9yVCV9KxBqtJw== X-Received: by 10.98.13.22 with SMTP id v22mr38966821pfi.125.1450128950441; Mon, 14 Dec 2015 13:35:50 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id sv8sm44878822pab.13.2015.12.14.13.35.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Dec 2015 13:35:50 -0800 (PST) Date: Mon, 14 Dec 2015 13:35:12 -0800 From: Stephen Hemminger To: "Ananyev, Konstantin" Message-ID: <20151214133512.48593b49@xeon-e3> In-Reply-To: <2601191342CEEE43887BDE71AB97725836AD3A5C@irsmsx105.ger.corp.intel.com> References: <1449853163-25673-1-git-send-email-stephen@networkplumber.org> <2601191342CEEE43887BDE71AB97725836AD3A0B@irsmsx105.ger.corp.intel.com> <20151214112516.35bbc1f8@xeon-e3> <2601191342CEEE43887BDE71AB97725836AD3A5C@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 21:35:51 -0000 On Mon, 14 Dec 2015 19:57:10 +0000 "Ananyev, Konstantin" wrote: > > > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Monday, December 14, 2015 7:25 PM > > To: Ananyev, Konstantin > > Cc: Zhang, Helin; dev@dpdk.org; Tom Kiely > > Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. > > > > On Mon, 14 Dec 2015 19:12:26 +0000 > > "Ananyev, Konstantin" wrote: > > > > > > > > > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > > > Sent: Friday, December 11, 2015 4:59 PM > > > > To: Zhang, Helin; Ananyev, Konstantin > > > > Cc: dev@dpdk.org; Tom Kiely; Stephen Hemminger > > > > Subject: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. > > > > > > > > From: Tom Kiely > > > > > > > > SRIOV VFs support "transparent" vlans. Traffic from/to a VM > > > > associated with a VF is tagged/untagged with the specified > > > > vlan in a manner intended to be totally transparent to the VM. > > > > > > > > The vlan is specified by "ip link set vf vlan ". > > > > The VM is not configured for any vlan on the VF and the VM > > > > should never see these transparent vlan headers 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 explicitly discards such vlan headers but DPDK > > > > does not. > > > > This patch mirrors the kernel behaviour for SRIOV VFs only > > > > > > > > > I have few concerns about that approach: > > > > > > 1. I don't think vlan_tci info should *always* be stripped by vf RX routine. > > > There could be configurations when that information might be needed by upper layer. > > > Let say VF can be member of 2 or more VLANs and upper layer would like to have that information > > > for further processing. > > > Or special mirror VF, that does traffic snnoping, or something else. > > > 2. Proposed implementation would introduce a slowdown for all VF RX routines. > > > 3. From the description it seems like the aim is to clear VLAN information for the RX packet. > > > Though the patch actually clears VLAN info only for the RX packet whose VLAN tag is not present inside SW copy of VFTA table. > > > Which makes no much point to me: > > > If VLAN is not present in HW VFTA table, then packet with that VLAN tag will be discarded by HW anyway. > > > If it is present inside VFTA table (both SW & HW), then VLAN information would be preserved with and without the patch. > > > > > > If you need to clear VLAN information, why not to do it on the upper layer - inside your application itself? > > > Either create some sort of wrapper around rx_burst(), or setup an RX call-back for your VF device. > > > > > > Konstantin > > > > > > The aim is to get SRIOV to work when the transparent VLAN tag feature is used. > > Please talk to the Linux driver team. Similar code exists there in ixgbevf_process_skb_fields. > > > Ah ok, I realised what you are trying to achieve now: > You setup HW VFTA[] from the PF, so from VF point of view SW copy of the VFTA[] remains unset. > So HW will pass VLAN packet in, but then SW will clear VLAN tag. > Ok, that clears #3 above, but I think #1,2 still remain. On the host, what configured is a vlan tag per VF per guest Tom had more info in the original mail. http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/28932 > > > > The other option is have a copy of all the receive logic which is only > > used by VF code. > > Why that's the only option? > Why can't you clear that VLAN information above the PMD layer? > Keep/obtain a copy of VFTA[] somewhere on the upper layer, > and do actual clear after rx_burst() returns? > Konstantin The problem is that the guest is supposed to not see the VLAN tags (it has no reason to), but the hardware leaves a VLAN tag on there.