patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Long Li <longli@microsoft.com>
To: Luca Boccassi <bluca@debian.org>,
	Long Li <longli@linuxonhyperv.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [dpdk-stable] [PATCH 19.11 2/2] net/netvsc: control use of external mbuf on Rx
Date: Thu, 10 Dec 2020 19:44:59 +0000	[thread overview]
Message-ID: <BN8PR21MB1155B52CE53FBC78EF3D1168CECB1@BN8PR21MB1155.namprd21.prod.outlook.com> (raw)
In-Reply-To: <8a602c1ef8439139feb88d3f0b90db5d7a98a8ae.camel@debian.org>

> Subject: Re: [dpdk-stable] [PATCH 19.11 2/2] net/netvsc: control use of
> external mbuf on Rx
> 
> On Wed, 2020-12-09 at 16:27 -0800, Long Li wrote:
> > From: Long Li <longli@microsoft.com>
> >
> > [ upstream commit 096b31fc0d8c989cc455c35f4d1def24a4ed6dee ]
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Signed-off-by: Long Li <longli@microsoft.com>
> > ---
> >  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?

This patch changes the default behavior of netvsc PMD to not use external mbufs on receiving data.

Using external mbufs has shown problems in many applications. Changing the default behavior will fix those.

Thanks,
Long

> 
> --
> Kind regards,
> Luca Boccassi

  reply	other threads:[~2020-12-10 19:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10  0:27 [dpdk-stable] [PATCH 19.11 1/2] net/netvsc: allow setting Rx and Tx copy break Long Li
2020-12-10  0:27 ` [dpdk-stable] [PATCH 19.11 2/2] net/netvsc: control use of external mbuf on Rx Long Li
2020-12-10 18:28   ` Luca Boccassi
2020-12-10 19:44     ` Long Li [this message]
2020-12-15 13:48       ` Luca Boccassi
2020-12-16  1:09         ` Stephen Hemminger
2020-12-16  2:16           ` Long Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN8PR21MB1155B52CE53FBC78EF3D1168CECB1@BN8PR21MB1155.namprd21.prod.outlook.com \
    --to=longli@microsoft.com \
    --cc=bluca@debian.org \
    --cc=longli@linuxonhyperv.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).