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 50B2AA09EF for ; Wed, 16 Dec 2020 02:09:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 23554C982; Wed, 16 Dec 2020 02:09:31 +0100 (CET) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by dpdk.org (Postfix) with ESMTP id CF3A0C982 for ; Wed, 16 Dec 2020 02:09:28 +0100 (CET) Received: by mail-pg1-f195.google.com with SMTP id k65so6129253pgk.0 for ; Tue, 15 Dec 2020 17:09:28 -0800 (PST) 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=Kdcfljjr51XHbNYOesPZ0u64yG6FkbHdPYvyIKFxXw8=; b=i3+QX9ItdxZUBOWELqlGrRkd0H7PpSA1vKUxiSD5pm83ggUPhGp+gapA9PizMPJKT5 fwU+RpLrgDV59cP7k/KmsKqy/ucBpjabC0PAAkyYYKU5F5IvR3+d7PGW+l7V+xFDJYA3 U1AKyYH2lQ+r/bGlVTxUw9RoLMdCqKaLpd17rhCLoShM6sTXsYLoqXmSUd0yzxwYT0ly vkDBreD91wi3a6CjWAGjhHoHWzmVxKckK98l0eE/kcOPSnaqhElGvwmdhMsipXY+xgkR C/Vb2EnjbFwZjHfqA3MlCu/9oeDthybjqdrhYn3NOtCSo3K6Kn5YXWoIJT+Tac2VCNCh MfmQ== 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=Kdcfljjr51XHbNYOesPZ0u64yG6FkbHdPYvyIKFxXw8=; b=g5H2drHxXjtJfmiOO7wlCF0Uj/gN/zDM9NHC1dd8dqmMFcUdqe2NwULzwBxWqSQtbC H10hNvMvvAp8xQNoWNpKIO2DZoVe0K7A0uRKTle3u8cw2Cp5nsJ1mSrswecC9DqqIj14 JhJYtHwPxS9TbVf046kJ6I1vO3Y8lecCJSIutVjyw+RH7fFhN7BZMHYU0I6vAfWEhS24 0VyIvfVFAJj0ULcE/lNJfSjj5pDgSZ7oa2v6pJUks9BhUyy7Ax+AlKrX9pDapX/CrlFP r7MzCCsBSRT1OHlGQUc8AVZ6kKPWbI6wGQmqiM2VS2KTVOsnw9dcQ74CHLNwjK7cmt8h +7ig== X-Gm-Message-State: AOAM532+h/graUsto58hGmGpr0KCCpi1+K3kKKcMQ5kpgOt4eYlVCPFp iKXRDUSNfaMnghS8rLzRcz0lKQ== X-Google-Smtp-Source: ABdhPJyGEZvRuETAyDfjhTLW6O4iwrM/TXCfm2xCb8roqWKEYh8SgXVUZMhxomFCUkfaLATFIs6rQA== X-Received: by 2002:a65:5b84:: with SMTP id i4mr31094875pgr.282.1608080966748; Tue, 15 Dec 2020 17:09:26 -0800 (PST) Received: from hermes.local (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u189sm213352pfb.51.2020.12.15.17.09.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Dec 2020 17:09:26 -0800 (PST) Date: Tue, 15 Dec 2020 17:09:23 -0800 From: Stephen Hemminger To: Luca Boccassi Cc: Long Li , Long Li , "stable@dpdk.org\" "@dpdk.org Message-ID: <20201215170923.3699aee6@hermes.local> In-Reply-To: <710a6ab5601097c0168312e6670ea20066db139b.camel@debian.org> References: <1607560037-30478-1-git-send-email-longli@linuxonhyperv.com> <1607560037-30478-2-git-send-email-longli@linuxonhyperv.com> <8a602c1ef8439139feb88d3f0b90db5d7a98a8ae.camel@debian.org> <710a6ab5601097c0168312e6670ea20066db139b.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 15 Dec 2020 13:48:57 +0000 Luca Boccassi wrote: > 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 > > > > > > On Wed, 2020-12-09 at 16:27 -0800, Long Li wrote: > > > > From: Long Li > > > > > > > > [ 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 > > > > --- > > > > 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. > > 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. > Can we just turn external mbuf usage in this driver off for the stable version instead?