From: Stephen Hemminger <stephen@networkplumber.org>
To: longli@linuxonhyperv.com
Cc: Wei Hu <weh@microsoft.com>, dev@dpdk.org, Long Li <longli@microsoft.com>
Subject: Re: [PATCH] net/netvsc: add device argument to configure if NUMA information on the device should be ignored
Date: Tue, 12 Aug 2025 17:35:14 -0700 [thread overview]
Message-ID: <20250812173514.1faf462b@hermes.local> (raw)
In-Reply-To: <1754952487-30601-1-git-send-email-longli@linuxonhyperv.com>
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
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?
next prev parent reply other threads:[~2025-08-13 0:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 22:48 longli
2025-08-13 0:35 ` Stephen Hemminger [this message]
2025-08-13 0:54 ` [EXTERNAL] " Long Li
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=20250812173514.1faf462b@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=longli@linuxonhyperv.com \
--cc=longli@microsoft.com \
--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).