From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) by dpdk.org (Postfix) with ESMTP id A6B4A5955 for ; Mon, 14 Dec 2015 20:25:08 +0100 (CET) Received: by pfbo64 with SMTP id o64so31554683pfb.1 for ; Mon, 14 Dec 2015 11:25:08 -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=RfDTL6qSFvdPOfH8Q//mJF3VbSfvHteddsqWHuDLYnc=; b=Xn8iBnqvGBq9juS2KZKMugeukHAqtQI+IPrzb+LLO7LhJsNwJCWHrPbqUZmolE7QAO +wjKQkRnx8fu6e6maJhY0PdyQxpgcDhwVQipziw3HCmW87OzbtdYz9BZHMA7JjCHX0eP 2lIPbIL4lPFlfw940wGDck5lCPvgEhNd+p+jc52zkVDkpdMEvMPB+ol5uSbW/79qL4VD j/Af1jB6tGMZw8FH0poAt91vX1AsownEbhsxmtey7nYxB4wkB/iOf/C9OsONqtvhaEh0 pliC7Vsy7PEZEAS0p73tBwgNtM3JJpIvQ2Sj5xlMm4pz3ydPXZxqKKbHQz2WNDrgElID zECQ== 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=RfDTL6qSFvdPOfH8Q//mJF3VbSfvHteddsqWHuDLYnc=; b=hGUR0+3qT3NZ0XJN4y3Vo3R7Tk7+fLlJPqDXSMQgFqSfZzCvJwDKZHVWcj+whiAT23 EJeE/ZIwcD17oxG+A/xabnNjPGlEISNrzGc+1LdanKTeZnd/y/x8g08MHmclJEaOg1cu LeCHKJErj21cyJcBEZ3FdLeRjjGSwv1dyaMlEEqMl052OzXbFEW7Os90RyXpJ/wP0Bdu 24RPl4hIg24Ow92u0oe97txzZbkG6sX//JK4Rd/YoqLbm1k4iQa+zrt6q7lZHfyUB/PN u43DbKf/Wv6KdfWML2GEbAlzS/2FNakyy1wsKcOhoqIR7dY2EUHr/QN/X8aOtXFsixVU /IHg== X-Gm-Message-State: ALoCoQmMpZZ6Aajwv9wOWNFmal4IxBdlONFRGLKMahAEkc899S+YJRORI9ysvyNCOrok+mLNB/gskXnXfCoU/jXs87zR0hpF+A== X-Received: by 10.98.72.133 with SMTP id q5mr38145713pfi.157.1450121108074; Mon, 14 Dec 2015 11:25:08 -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 q70sm44077261pfa.12.2015.12.14.11.25.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Dec 2015 11:25:07 -0800 (PST) Date: Mon, 14 Dec 2015 11:25:16 -0800 From: Stephen Hemminger To: "Ananyev, Konstantin" Message-ID: <20151214112516.35bbc1f8@xeon-e3> In-Reply-To: <2601191342CEEE43887BDE71AB97725836AD3A0B@irsmsx105.ger.corp.intel.com> References: <1449853163-25673-1-git-send-email-stephen@networkplumber.org> <2601191342CEEE43887BDE71AB97725836AD3A0B@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 19:25:09 -0000 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. The other option is have a copy of all the receive logic which is only used by VF code. Tom has more details. But you can reproduce problem by just testing current code with the transparent VLAN option.