From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by dpdk.space (Postfix) with ESMTP id 07843A0679
	for <public@inbox.dpdk.org>; Fri,  5 Apr 2019 01:54:59 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id B3BE71B3A7;
	Fri,  5 Apr 2019 01:54:58 +0200 (CEST)
Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com
 [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id 917DB1B3A5
 for <dev@dpdk.org>; Fri,  5 Apr 2019 01:54:56 +0200 (CEST)
Received: by mail-pg1-f194.google.com with SMTP id 85so2036636pgc.3
 for <dev@dpdk.org>; Thu, 04 Apr 2019 16:54:56 -0700 (PDT)
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-transfer-encoding;
 bh=tqsOW1rPocxVwIUlVd+0aHFlqrUVhZ+lDNiNL7QyiS8=;
 b=nmnwe0URnDN+q5EGQhgRS+sWb73BvJcR3LrRMNbhJglLm5ramSMPVrHE26QQt+POA+
 r1zLeuyfqld9Qg32C74vRg9vN639oR8QBQStw6+sBkFEShfwcDSqlcRf3mbO0CH27ZxZ
 AKkvLeAEs9pEwt1CmOrHgvMXGAbLscrlEY5105dZ3xt3EuOoq1I6NG5NlLE4w6+bvBAp
 SoLGMTrENpf4SRgNKP+ErvCogH9N5Zl+Yv0w9XYh73CF7RnsJTHQy8M5nDF0+nws7M0B
 azqkIjwDnwmGvu30WECDyhTwCm0k5HFCxfXacFVNhBxbenWOjaQbg+3aQ6JJjIBkj/LE
 FK1g==
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=tqsOW1rPocxVwIUlVd+0aHFlqrUVhZ+lDNiNL7QyiS8=;
 b=JfuuD9U1IawrBkolRclhe40IaXON+eDoxTz7y6icLMkTj+2DAjHXRb5Fig//H13qYA
 KSYiRwKtg0LGK4C7Hf+jxzL/yRHYEPmY8JOw83gvXpsGhphCJELPatRaPAQtcAaD7hGw
 W/5HsxWDg13+tSQ9WpTqqb+7VgcKiPVcWBEYsUr8oUJ6kUQEtjwumlwmSmB8iXvUggZ+
 3gXMu9/LlKQuyu6YIg6Qn5cBRzv83Lu8ixgQ3zRJsa3s5iV7tFd86OeOGgwCyzm0QBmJ
 kGY6nv5cOdNdaWhNnwBt9k/h2gou0E72mUoVA7BS0X29Chod+ZHcHNCIpMQCNMLSnkW5
 J8Wg==
X-Gm-Message-State: APjAAAUhRv1r2k+kmxmqvkFCObEwfn18Yx3AbSrxTkrXVLYpY/vOzZ0l
 WSkocng4jToiR+rnU0byuLtGBw==
X-Google-Smtp-Source: APXvYqxRg4QR9QYOIsb0HAlE7sA0mPTUgGRPd3MOx23NGQJU8Mt9Q+AAihN7+px1CVfI6KmoStRhVQ==
X-Received: by 2002:a63:c944:: with SMTP id y4mr8369030pgg.257.1554422094768; 
 Thu, 04 Apr 2019 16:54:54 -0700 (PDT)
Received: from shemminger-XPS-13-9360 ([167.220.104.127])
 by smtp.gmail.com with ESMTPSA id c1sm27747319pfd.114.2019.04.04.16.54.54
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Thu, 04 Apr 2019 16:54:54 -0700 (PDT)
Date: Thu, 4 Apr 2019 16:54:49 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Chas Williams <3chas3@gmail.com>
Cc: dev@dpdk.org, Stephen Hemminger <sthemmin@microsoft.com>
Message-ID: <20190404165449.0f7ea879@shemminger-XPS-13-9360>
In-Reply-To: <bcaedd78-69c9-4f6b-b5d8-6b17707b325a@gmail.com>
References: <b2518429-e988-8bfa-24d2-d3bc6f95d446@intel.com>
 <20190328205322.852-1-stephen@networkplumber.org>
 <bcaedd78-69c9-4f6b-b5d8-6b17707b325a@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [RFC v2] net: fix rte_vlan_insert with shared mbuf
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Message-ID: <20190404235449.8Y9Gjj0Q0K8o3fCPY83QHMjsYTBsTLvPM_AbKN9q60Q@z>

On Sat, 30 Mar 2019 08:41:33 -0400
Chas Williams <3chas3@gmail.com> wrote:

> Unfortunately, I think the complete fix is more complicated than this.
> Drivers that use rte_vlan_insert don't anticipate that the mbuf might
> change and that (hardware) transmit can fail.
> 
> They make a copy of the mbuf pointer from the incoming transmit list
> and don't update the original if rte_vlan_insert creates a new mbuf.
> If transmit fails, the application needs to be the given the new mbuf
> for re-transmission or freeing.
> 
> On 3/28/19 4:53 PM, Stephen Hemminger wrote:
> > If mbuf is shared then rte_vlan_insert() would clobber the original
> > Ethernet header. The changed version handles this by getting
> > an mbuf that will hold the new Ethernet and VLAN header followed
> > by another mbuf (cloned) for the data.
> > 
> > Fixes: c974021a5949 ("ether: add soft vlan encap/decap")
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>

The virtio driver is buggy, it saves original mbuf and doesn't handle
rewrite. Dpaa2 is fine, should never happen since it checks refcnt etc.
Netvsc PMD is using this on rx path and is safe.
AF_packet PMD should work fine as well.

So virtio is the one that needs fixing