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 E3D32A04DB for ; Thu, 10 Dec 2020 19:28:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BE77BBC8A; Thu, 10 Dec 2020 19:28:54 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 14D0CBC8A for ; Thu, 10 Dec 2020 19:28:54 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id t16so6506185wra.3 for ; Thu, 10 Dec 2020 10:28:54 -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=6pG6UYLcezw323MyyUPZDb7xVTgsIUXl9qed4R8n3os=; b=oZShPikfV1O/cHezkxbDv8pxGGj2O2i631Gb2V6aRqXIFni7PCbGXFXzeI9IPDK6zr jqvGaNAAX6KyEGlN5zlGPNxiSCsXbWMTNBR9D8irN9MsfbypjWc/24OLkhjtbqSNco44 4w8cNW77KqmPUx5JmGpPB1N7qfWu9GFCO5OGmCT51fXi/YfFRLJk3+sLlCNdPWWQQVp3 qggbjuz3OULgVNjwGIrW1x/QDr5wH3lfY51vTcu/nCI+cVSB5YCo7cBre2hFnMLDztbF G4R7vOeUmUGPrlmuSg4qCMJ1GcQ22VaR8eHP2yE9O2dK3zLDCeTBl6GNgFW/BlGTcawh RSDw== X-Gm-Message-State: AOAM530AxnM69rvVCWEKckhz1oBCipUKzf/0A5iPgDlVKLjq+zMkTmyU bhO58Oe27wdfZPL6QebLbQ0a+0CTpF2V3w== X-Google-Smtp-Source: ABdhPJwlMT2r9I/uCE3+S9y3FEqnA8hKtHvWnLmDhTlQI5fd0yfVnxByJ+Edl+vdW+HhW9NM7Pbmcw== X-Received: by 2002:a5d:4641:: with SMTP id j1mr9709850wrs.94.1607624932801; Thu, 10 Dec 2020 10:28:52 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id x7sm3282096wmi.11.2020.12.10.10.28.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 10:28:51 -0800 (PST) Message-ID: <8a602c1ef8439139feb88d3f0b90db5d7a98a8ae.camel@debian.org> From: Luca Boccassi To: Long Li , stable@dpdk.org Cc: Long Li , Stephen Hemminger Date: Thu, 10 Dec 2020 18:28:50 +0000 In-Reply-To: <1607560037-30478-2-git-send-email-longli@linuxonhyperv.com> References: <1607560037-30478-1-git-send-email-longli@linuxonhyperv.com> <1607560037-30478-2-git-send-email-longli@linuxonhyperv.com> 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 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 UIO. > 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 external mbuf. >=20 > 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. If > 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 buffers > 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(-) 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? In general, we do not take new features in LTS releases. Stable means stable - we make very few exceptions. Is the PMD broken/unusable without these options? --=20 Kind regards, Luca Boccassi