> Subject: [EXTERNAL] Re: [PATCH v2] bus/vmbus: add device argument to > configure if NUMA information on the device should be ignored > > On Mon, 18 Aug 2025 17:24:26 -0700 > lon...@linuxonhyperv.com wrote: > > > From: Long Li <lon...@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 patch adds a device argument "numa" to allow the application to > > configure if this vmbus device (netvsc) should be NUMA aware. The > > default behavior is NUMA aware. Setting "numa=0" specifies this vmbus > > device is not NUMA aware. > > > > The device argument is parsed at the time of vmbus device probe to > > ensure all the following memory allocations are done on the configured > NUMA node. > > > > Signed-off-by: Long Li <lon...@microsoft.com> > > Putting all the args in vmbus seems confusing, and not what I meant. > Was more thing that ethdev and queues should be on same NUMA node. > > If NUMA is better why wouldn't it always be on? > Since netvsc is really a virtual device not sure. > I suspect 99% of users will be using with VF, that should be the default.
Sorry I misread your previous comment on handling this in VMBUS code. I'm still a little confused. Should I add a "numa_aware" device argument for netvsc, and have VMBUS code to parse this argument before calling the device probe function of netvsc? Maybe all the vmbus device should default to be not NUMA aware. But I don't know if there are use cases using netvsc without VF and if NUMA makes a difference in those situations. It's difficult to decide the NUMA node for a VF in advance, since they can be hot added at any time after DPDK starts.
