From: Long Li <longli@microsoft.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
"longli@linuxonhyperv.com" <longli@linuxonhyperv.com>
Cc: Wei Hu <weh@microsoft.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [EXTERNAL] Re: [PATCH v2] bus/vmbus: add device argument to configure if NUMA information on the device should be ignored
Date: Wed, 20 Aug 2025 23:08:08 +0000 [thread overview]
Message-ID: <IA4PR21MB4736D319A0D0D584997FE5D6CE33A@IA4PR21MB4736.namprd21.prod.outlook.com> (raw)
In-Reply-To: <20250820124952.7cd930cb@hermes.local>
> 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
> 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 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 <longli@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.
prev parent reply other threads:[~2025-08-20 23:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 0:24 longli
2025-08-20 19:49 ` Stephen Hemminger
2025-08-20 23:08 ` Long Li [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=IA4PR21MB4736D319A0D0D584997FE5D6CE33A@IA4PR21MB4736.namprd21.prod.outlook.com \
--to=longli@microsoft.com \
--cc=dev@dpdk.org \
--cc=longli@linuxonhyperv.com \
--cc=stephen@networkplumber.org \
--cc=weh@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).