RE: [EXTERNAL] Re: [PATCH] net/netvsc: add device argument to configure if NUMA information on the device should be ignored

[Long Li <longli@microsoft.com>]

> Subject: [EXTERNAL] Re: [PATCH] net/netvsc: add device argument to
> configure if NUMA information on the device should be ignored
> 
> On Mon, 11 Aug 2025 15:48:07 -0700
> longli@linuxonhyperv.com wrote:
> 
> > From: Long Li <longli@microsoft.com>
> >
> > 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.
> >
> > Signed-off-by: Long Li <longli@microsoft.com>
> 
> 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

How about using a parameter name like "numa_aware"?

> 
> The VMBus channels are being created before the device is probed.
> And those end up being set before the probe is called.
> 
> > @@ -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?

Okay, I will move those to VMBUS code.

Long