DPDK patches and discussions
 help / color / mirror / Atom feed
From: Long Li <longli@linuxonhyperv.com>
To: Stephen Hemminger <sthemmin@microsoft.com>
Cc: dev@dpdk.org, Long Li <longli@microsoft.com>
Subject: [dpdk-dev] [PATCH V2 2/2] net/netvsc: introduce driver parameter to control the use of external mbuf on receiving data
Date: Fri, 23 Oct 2020 14:54:35 -0700	[thread overview]
Message-ID: <1603490075-6840-2-git-send-email-longli@linuxonhyperv.com> (raw)
In-Reply-To: <1603490075-6840-1-git-send-email-longli@linuxonhyperv.com>

From: Long Li <longli@microsoft.com>

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 | 7 +++++++
 drivers/net/netvsc/hn_rxtx.c   | 2 +-
 drivers/net/netvsc/hn_var.h    | 3 +++
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst
index 5a68ffa8a3..19f9940fe6 100644
--- a/doc/guides/nics/netvsc.rst
+++ b/doc/guides/nics/netvsc.rst
@@ -133,3 +133,11 @@ The user can specify below argument in devargs.
     set larger than the MTU, then all packets smaller than the chunk size
     of the VMBus send buffer will be copied; larger packets always have to
     go as a single direct request. The default value is 512 (bytes).
+#.  ``rx_extmbuf_enable``:
+    The rx_extmbuf_enable is used 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 received data to mbuf)
+    A non-zero value tells netvsc to attach external buffers to mbuf on
+    receiving packets, thus avoid copying memory. Use of external buffers
+    requires the application is able to read data from external mbuf.
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index 2de951bae9..2d78a0118c 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -48,6 +48,7 @@
 #define NETVSC_ARG_LATENCY "latency"
 #define NETVSC_ARG_RXBREAK "rx_copybreak"
 #define NETVSC_ARG_TXBREAK "tx_copybreak"
+#define NETVSC_ARG_RX_EXTMBUF_ENABLE "rx_extmbuf_enable"
 struct hn_xstats_name_off {
@@ -164,6 +165,10 @@ static int hn_set_parameter(const char *key, const char *value, void *opaque)
 		hv->tx_copybreak = v;
 		PMD_DRV_LOG(DEBUG, "tx copy break set to %u",
+	} else if (!strcmp(key, NETVSC_ARG_RX_EXTMBUF_ENABLE)) {
+		hv->rx_extmbuf_enable = v;
+		PMD_DRV_LOG(DEBUG, "rx extmbuf enable set to %u",
+			    hv->rx_extmbuf_enable);
 	return 0;
@@ -178,6 +183,7 @@ static int hn_parse_args(const struct rte_eth_dev *dev)
 	struct rte_kvargs *kvlist;
@@ -987,6 +993,7 @@ eth_hn_dev_init(struct rte_eth_dev *eth_dev)
 	hv->latency = HN_CHAN_LATENCY_NS;
 	hv->rx_copybreak = HN_RXCOPY_THRESHOLD;
 	hv->tx_copybreak = HN_TXCOPY_THRESHOLD;
+	hv->rx_extmbuf_enable = HN_RX_EXTMBUF_ENABLE;
 	hv->max_queues = 1;
diff --git a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c
index ce75b4d092..35c046b1a7 100644
--- a/drivers/net/netvsc/hn_rxtx.c
+++ b/drivers/net/netvsc/hn_rxtx.c
@@ -565,7 +565,7 @@ static void hn_rxpkt(struct hn_rx_queue *rxq, struct hn_rx_bufinfo *rxb,
 	 * For large packets, avoid copy if possible but need to keep
 	 * some space available in receive area for later packets.
-	if (dlen > hv->rx_copybreak &&
+	if (hv->rx_extmbuf_enable && dlen > hv->rx_copybreak &&
 	    (uint32_t)rte_atomic32_read(&rxq->rxbuf_outstanding) <
 			hv->rxbuf_section_cnt / 2) {
 		struct rte_mbuf_ext_shared_info *shinfo;
diff --git a/drivers/net/netvsc/hn_var.h b/drivers/net/netvsc/hn_var.h
index c1bdafb413..9dcb669f7a 100644
--- a/drivers/net/netvsc/hn_var.h
+++ b/drivers/net/netvsc/hn_var.h
@@ -26,6 +26,8 @@
 /* Buffers need to be aligned */
 #ifndef PAGE_SIZE
 #define PAGE_SIZE 4096
@@ -118,6 +120,7 @@ struct hn_data {
 	struct rte_mem_resource *rxbuf_res;	/* UIO resource for Rx */
 	uint32_t	rxbuf_section_cnt;	/* # of Rx sections */
 	uint32_t	rx_copybreak;
+	uint32_t	rx_extmbuf_enable;
 	uint16_t	max_queues;		/* Max available queues */
 	uint16_t	num_queues;
 	uint64_t	rss_offloads;

  reply	other threads:[~2020-10-23 21:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23 21:54 [dpdk-dev] [PATCH V2 1/2] net/netvsc: allow setting rx and tx copy break Long Li
2020-10-23 21:54 ` Long Li [this message]
2020-10-29 20:00 ` Ferruh Yigit
2020-10-31  5:59   ` 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:

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

  git send-email \
    --in-reply-to=1603490075-6840-2-git-send-email-longli@linuxonhyperv.com \
    --to=longli@linuxonhyperv.com \
    --cc=dev@dpdk.org \
    --cc=longli@microsoft.com \
    --cc=sthemmin@microsoft.com \


* 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).