From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2250DA09EE for ; Tue, 15 Dec 2020 14:49:04 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E4A96CA36; Tue, 15 Dec 2020 14:49:02 +0100 (CET) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 6170ACA36 for ; Tue, 15 Dec 2020 14:49:00 +0100 (CET) Received: by mail-wm1-f68.google.com with SMTP id x22so16932282wmc.5 for ; Tue, 15 Dec 2020 05:49:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=YHPw7WgaWVums9iJ6i6/J9FTPCuXWwZx5cnZdz403os=; b=P5TczpxIh6/Ouq7+INBtpfMEBMpoPZN4zVWrGWby92rUEimVB8hqQsUqHYj4F3Cr/r lliphDAjtuSMwPu/Xx33NU+VpeSoMytzM1yFCIMjYZoB9CQ3su7hrMGuoN/eFlFOJIDB 0IxGSryq07VDOJeqjVNsrDc/ngf4F360dS+6zbQ5yC0KliL1jkfR34O5Vx6f48ifVeGM wSJqOhMIEX1asYAqAjV9wg5pUzGeo+lOP7ers8+8gVEe/rL+DaXNCGYr8/3y+TBO9U4s 4lwHSvidi6FloHRcAupAZuFIl9id5SikzrvX0biV1rWjFXrp4ReSBc/5hBI9plwzyfmx HXJg== X-Gm-Message-State: AOAM531Jpf1a5RMuKdb+v42nIdO+3dbBT6BFVSdHm7JxvvgRnDTJc8kK It7rzEuCZ9Ckja4v7qhyfbc= X-Google-Smtp-Source: ABdhPJxGB4BhU6OqxyWhZSwY6CSOYwHN3MzC4ogt55GwUKEVkE1h85LO90PjhJUxt9KSdhyBgZkGNw== X-Received: by 2002:a1c:4645:: with SMTP id t66mr32516873wma.152.1608040139114; Tue, 15 Dec 2020 05:48:59 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id v11sm8132384wrt.25.2020.12.15.05.48.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Dec 2020 05:48:58 -0800 (PST) Message-ID: <710a6ab5601097c0168312e6670ea20066db139b.camel@debian.org> From: Luca Boccassi To: Long Li , Long Li , "stable@dpdk.org" Cc: Stephen Hemminger Date: Tue, 15 Dec 2020 13:48:57 +0000 In-Reply-To: References: <1607560037-30478-1-git-send-email-longli@linuxonhyperv.com> <1607560037-30478-2-git-send-email-longli@linuxonhyperv.com> <8a602c1ef8439139feb88d3f0b90db5d7a98a8ae.camel@debian.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.2 MIME-Version: 1.0 Subject: Re: [dpdk-stable] [PATCH 19.11 2/2] net/netvsc: control use of external mbuf on Rx X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Thu, 2020-12-10 at 19:44 +0000, Long Li wrote: > > Subject: Re: [dpdk-stable] [PATCH 19.11 2/2] net/netvsc: control use of > > external mbuf on Rx > >=20 > > On Wed, 2020-12-09 at 16:27 -0800, Long Li wrote: > > > From: Long Li > > >=20 > > > [ upstream commit 096b31fc0d8c989cc455c35f4d1def24a4ed6dee ] > > >=20 > > > When receiving packets, netvsp puts data in a buffer mapped through U= IO. > > > Depending on packet size, netvsc may attach the buffer as an external > > > mbuf. This is not a problem if this mbuf is consumed in the > > > application, and the application can correctly read data out of an ex= ternal > > mbuf. > > > However, there are two problems with data in an external mbuf. > > > 1. Due to the limitation of the kernel UIO implementation, physical > > > address of this external buffer is not exposed to the user-mode. I= f > > > this mbuf is passed to another driver, the other driver is unable = to > > > map this buffer to iova. > > > 2. Some DPDK applications are not aware of external mbuf, and may bug > > > when they receive an mbuf with external buffer attached. > > >=20 > > > Introduce a driver parameter "rx_extmbuf_enable" to control if netvsc > > > should use external mbuf for receiving packets. The default value is = 0. > > > (netvsc doesn't use external mbuf, it always allocates mbuf and copy > > > data to mbuf) A non-zero value tells netvsc to attach external buffer= s > > > to mbuf on receiving packets, thus avoid copying memory. > > >=20 > > > Signed-off-by: Long Li > > > --- > > > doc/guides/nics/netvsc.rst | 8 ++++++++ > > > drivers/net/netvsc/hn_ethdev.c | 10 +++++++++- > > > drivers/net/netvsc/hn_rxtx.c | 2 +- > > > drivers/net/netvsc/hn_var.h | 3 +++ > > > 4 files changed, 21 insertions(+), 2 deletions(-) > >=20 > > Correct me if I'm wrong, but these 2 patches look a bit more like new > > features than bug fixes? It's new options for the PMD, right? > >=20 > > In general, we do not take new features in LTS releases. Stable means s= table > > - we make very few exceptions. > >=20 > > Is the PMD broken/unusable without these options? >=20 > This patch changes the default behavior of netvsc PMD to not use external= mbufs on receiving data. >=20 > Using external mbufs has shown problems in many applications. Changing th= e default behavior will fix those. Sorry but I don't think adding new options is appropriate for an LTS release. The expectations is that everything works as-is without any need to even recompile, let alone changing options. --=20 Kind regards, Luca Boccassi