From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by dpdk.org (Postfix) with ESMTP id CC84E2C55 for ; Wed, 29 Mar 2017 09:20:40 +0200 (CEST) Received: by mail-wr0-f174.google.com with SMTP id l43so4433672wre.1 for ; Wed, 29 Mar 2017 00:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1iWSZQJGqx8xY1MGjzJkb2Sj5Y4k8Vkz6iengvC04Nk=; b=N4FkyM6aAu8z/hYUMnNCbVQmgw0rg81m537C9TFOfdKXd34AggzV7Sox3Almrnvp3S xf1QyQ9v210qEqiUPwEYXPXTabF5JCML+LzPob12gXmEfrCYDDqBYeibD9P06pp0O/Yu /dDjkBgxH6UVFxTzvHl8o9Pfspj62O+EeWYTJfhO7KhalRT8OBCgw5fw9dgMX32R5Dpx HwNLfbqWKVBi7LN5gYlIGHtI6ZrHTodEuQl6Y791Wl7A3P4eOynbQZ1YG/GRgnc9u1JV QGUrMTYaeQyCbrIzS3ZDi2Q+wJDekboh2qjy/wjYxeByqoFjykpPo2Fmi6291kjuM6B7 2IcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1iWSZQJGqx8xY1MGjzJkb2Sj5Y4k8Vkz6iengvC04Nk=; b=UkECqYZPh2v46CctDvnMLlIPeuYfts2/wJ3T5dVrL2jlrdF8dbGkJr2WJReyFMzbBT iuYCYdMBaiUKRlBuL82CtCazPMkXPsBP6j6dqUVfOCa64XCPQ04nPmnct3+NelUS/EcV 6X9hFS/nv8vn7dYsLL0JlT8xD+Je8dEWR5Cb/LNJ3oG4k8+WLYvUZ1L9eRoTAHPQvWuH lVNUYvpHmw+mKH6w7F60qWur3s+MYyHhErYzOyLrvPautN8MZS0ddTd+13pYTL6NiLXt iIUtiasvj3ByMy3hYKSheHxBVPNvLApXPCLDBfPf8XNybZ+59Cj2GUqaNyXVNWohWSXM qOCw== X-Gm-Message-State: AFeK/H1UXc9qYO2IPbuZ/p14ueWxYQhvP2C0G4x2RBkwA4fZEXpjzqQzJo0r5Wq09su39/vt X-Received: by 10.223.161.134 with SMTP id u6mr18122214wru.113.1490772040414; Wed, 29 Mar 2017 00:20:40 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id d29sm6709589wmi.21.2017.03.29.00.20.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Mar 2017 00:20:40 -0700 (PDT) Date: Wed, 29 Mar 2017 09:20:36 +0200 From: Olivier Matz To: "Wu, Jingjing" Cc: "dev@dpdk.org" , "Zhang, Helin" Message-ID: <20170329092036.26d3b996@platinum> In-Reply-To: <9BB6961774997848B5B42BEC655768F810D19603@SHSMSX103.ccr.corp.intel.com> References: <20170328172943.7b157ef4@platinum> <9BB6961774997848B5B42BEC655768F810D19603@SHSMSX103.ccr.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] disable i40e vf vlan stripping 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: Wed, 29 Mar 2017 07:20:41 -0000 Hi Jingjing, On Wed, 29 Mar 2017 02:53:15 +0000, "Wu, Jingjing" wrote: > > -----Original Message----- > > From: Olivier Matz [mailto:olivier.matz@6wind.com] > > Sent: Tuesday, March 28, 2017 11:30 PM > > To: dev@dpdk.org; Zhang, Helin ; Wu, Jingjing > > > > Subject: disable i40e vf vlan stripping > > > > Hi i40e maintainers, > > > > I have the following configuration: > > - host runs with Linux pf i40e driver > > - guest runs with DPDK vf i40e driver > > > > I send a vlan packet from the host to the guest. > > On the guest, I start testpmd with --disable-hw-vlan-strip. > > > > When I receive the packet on the guest, it has the PKT_RX_VLAN_STRIPPED flag > > although I'm not asking for it. From what I understand, it is not possible to > > disable vlan stripping when using a Linux PF driver. > > > > Since the i40evf DPDK driver does not behave like what the application asks for, > > I think it should be fixed. What do you think about re-adding the vlan in > > software when dev_conf->rxmode.hw_vlan_strip == 0 ? > > > > The other alternative would be to forbid this configuration and return an error. > > > We faced the same issue with hw_crc_strip, and now the code is consider it as an error. > The issue is hw_vlan_strip/hw_crc_strip mode is inconsistent between VF and PF. > Evne I think it should not be an error to block the VF start up. But I'm fine if you think it is an error. > > The ideal way maybe the capability negotiate between VF and PF. Let's think about it. I'm not sure that you are suggesting to add an ethdev capability flag here, but I think that would be a bit odd. To clarify, having flags to advertise the support of an offload feature makes sense, but having flags to advertise that not using the offload is supported looks strange. Negotiating with the PF and returning an error if vlan_strip=0 is not supported at port configuration, is the worst acceptable option, because it prevents applications that do not handle offload flags to work (which is probably the majority of applications). I think that the best think to do, in terms of usability, is to have a software fall-back in the driver that adds the vlan in the packet data in that case. It would be transparent to the application. To me, the "no offload" behavior is part of the basic features that all PMDs should support (it could be interesting to have a list of these features by the way). Regards, Olivier