On 10/22/2020 8:46 PM, Long Li wrote:
From: Long Li <lon...@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 <lon...@microsoft.com>
---
drivers/net/netvsc/hn_ethdev.c | 11 +++++++++++
drivers/net/netvsc/hn_rxtx.c | 2 +-
drivers/net/netvsc/hn_var.h | 3 +++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index e4f13b962c..735fc6d236 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"
Same comments for with previous patch, can you please document the new devarg
and 'rte_kvargs_process()' can be used to parse it.
