net/netvsc: add device argument to configure if NUMA information on the device should be ignored
PATCH 1/1 net/netvsc: add device argument to configure if NUMA information on the device should be ignored
From: Long Li <[email protected]>
In most cases, netvsc is used with a VF device. The application generally runs with better performance when all the device memory is allocated on VF's NUMA node, as the VF device carries most of the data packets.
But sometimes netvsc may run on a different NUMA node than that of the VF. This patches adds a device argument "numa" to allow the application to configure if netvsc should be NUMA aware. The default behavior for netvsc is that it is NUMA aware. Setting "numa=0" tells netvsc not to be NUMA aware.
--- doc/guides/nics/netvsc.rst | 8 +++++ drivers/net/netvsc/hn_ethdev.c | 66 +++++++++++++++++++++++++++++----- 2 files changed, 66 insertions(+), 8 deletions(-)
doc/guides/nics/netvsc.rst +8 -0
@@ -141,3 +141,11 @@ The user can specify below argument in devargs. 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. + +#. ``numa``: + The numa is used to configure if netvsc driver should be NUMA aware. The + default value is 1 (meaning the netvsc driver is NUMA aware). When used + with a VF device, the VF device's NUMA node may not be the same as netvsc's + NUMA node. The application generally runs with better performance if all the + device queues are allocated on VF's NUMA node, as the VF carries most of the + data packets. Setting this value to 0 makes netvsc driver not NUMA aware.
drivers/net/netvsc/hn_ethdev.c +58 -8
96 lines not on this page · raw message
Signature · 1 line
2.34.1
Quoted 6 lines · On Mon, 11 Aug 2025 15:48:07 -0700 [email protected] wrote:
From: Long Li <[email protected]>
In most cases, netvsc is used with a VF device. The application generally runs with better performance when all the device memory is allocated on VF's NUMA node, as the VF device carries most of the data packets.
Quoted 7 lines
But sometimes netvsc may run on a different NUMA node than that of the VF. This patches adds a device argument "numa" to allow the application to configure if netvsc should be NUMA aware. The default behavior for netvsc is that it is NUMA aware. Setting "numa=0" tells netvsc not to be NUMA aware.
Signed-off-by Long Li <[email protected]>
Using 0 as "not numa" seems odd because NUMA node 0 is a valid node id. SOCKET_ID_ANY is defined as -1 in rte_memory.h
The VMBus channels are being created before the device is probed. And those end up being set before the probe is called.
drivers/net/netvsc/hn_ethdev.c eth_dev_vmbus_allocate(struct rte_vmbus_device *dev, size_t private_data_size) · line 189
Quoted 9 lines
drivers/net/netvsc/hn_ethdev.c +1
-1@@ -126,7 +183,7 @@ eth_dev_vmbus_allocate(struct rte_vmbus_device *dev, size_t private_data_size)if (private_data_size) { eth_dev->data->dev_private =rte_zmalloc_socket (name, private_data_size, -RTE_CACHE_LINE_SIZE , dev->device.numa_node); +RTE_CACHE_LINE_SIZE , dev->device.numa_node);if (!eth_dev->data->dev_private) {PMD_DRV_LOG (NOTICE ,"can not allocate driver data" );rte_eth_dev_release_port (eth_dev);
No need to change indentation here. Yes alignment with paren is nicer but better to just focus patch on one thing.
Maybe this should be handled in vmbus then it could get all the allocations right?
Quoted 20 lines
Subject: [EXTERNAL] Re: [PATCH] net/netvsc: add device argument to configure if NUMA information on the device should be ignored
Quoted 5 lines · On Mon, 11 Aug 2025 15:48:07 -0700 [email protected] wrote:
From: Long Li <[email protected]>
In most cases, netvsc is used with a VF device. The application generally runs with better performance when all the device memory is allocated on VF's NUMA node, as the VF device carries most of the data
packets.
Quoted 2 lines
But sometimes netvsc may run on a different NUMA node than that of the
VF.
Quoted 5 lines
This patches adds a device argument "numa" to allow the application to configure if netvsc should be NUMA aware. The default behavior for netvsc is that it is NUMA aware. Setting "numa=0" tells netvsc not to be NUMA aware.
Quoted 4 lines
Quoted 1 line
Signed-off-by Long Li <[email protected]>Using 0 as "not numa" seems odd because NUMA node 0 is a valid node id.
SOCKET_ID_ANYis defined as -1 inrte_memory.h
How about using a parameter name like "numa_aware"?
Quoted 16 lines
The VMBus channels are being created before the device is probed. And those end up being set before the probe is called.
Review eth_dev_vmbus_allocate(struct rte_vmbus_device
Quoted 1 line
(quoted diff) +0
-0@@ -126,7 +183,7 @@ eth_dev_vmbus_allocate(struct rte_vmbus_device*dev,
size_tprivate_data_size)drivers/net/netvsc/hn_ethdev.c eth_dev_vmbus_allocate(struct rte_vmbus_device *dev, size_t private_data_size)
Quoted 4 lines
drivers/net/netvsc/hn_ethdev.c +0
-1if (private_data_size) { eth_dev->data->dev_private = rte_zmalloc_socket(name, private_data_size, - RTE_CACHE_LINE_SIZE,
dev->device.numa_node);Review eth_dev_vmbus_allocate(struct rte_vmbus_device · line 189
Quoted 4 lines
(quoted diff) +1
-0+ RTE_CACHE_LINE_SIZE, dev- device.numa_node); if (!eth_dev->data->dev_private) { PMD_DRV_LOG(NOTICE, "can not allocatedriver data");
Quoted 7 lines
Quoted 1 line
rte_eth_dev_release_port(eth_dev);No need to change indentation here. Yes alignment with paren is nicer but better to just focus patch on one thing.
Maybe this should be handled in vmbus then it could get all the allocations right?
Okay, I will move those to VMBUS code.
Long