From: Yury Norov <yury.norov@gmail.com>
To: Tariq Toukan <ttoukan.linux@gmail.com>
Cc: Erwan Velu <erwanaliasr1@gmail.com>,
Erwan Velu <e.velu@criteo.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Tariq Toukan <tariqt@nvidia.com>, Yury Norov <ynorov@nvidia.com>,
Rahul Anand <raanand@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/mlx5: Use cpumask_local_spread() instead of custom code
Date: Wed, 14 Aug 2024 07:45:36 -0700 [thread overview]
Message-ID: <ZrzDAlMiEK4fnLmn@yury-ThinkPad> (raw)
In-Reply-To: <3dcbfb0d-6e54-4450-a266-bf4701e77e08@gmail.com>
On Wed, Aug 14, 2024 at 10:48:40AM +0300, Tariq Toukan wrote:
>
>
> On 12/08/2024 11:22, Erwan Velu wrote:
> > Commit 2acda57736de ("net/mlx5e: Improve remote NUMA preferences used for the IRQ affinity hints")
> > removed the usage of cpumask_local_spread().
> >
> > The issue explained in this commit was fixed by
> > commit 406d394abfcd ("cpumask: improve on cpumask_local_spread() locality").
> >
> > Since this commit, mlx5_cpumask_default_spread() is having the same
> > behavior as cpumask_local_spread().
> >
>
> Adding Yuri.
>
> One patch led to the other, finally they were all submitted within the same
> patchset.
>
> cpumask_local_spread() indeed improved, and AFAIU is functionally equivalent
> to existing logic.
> According to [1] the current code is faster.
> However, this alone is not a relevant enough argument, as we're talking
> about slowpath here.
>
> Yuri, is that accurate? Is this the only difference?
>
> If so, I am fine with this change, preferring simplicity.
>
> [1] https://elixir.bootlin.com/linux/v6.11-rc3/source/lib/cpumask.c#L122
If you end up calling mlx5_cpumask_default_spread() for each CPU, it
would be O(N^2). If you call cpumask_local_spread() for each CPU, your
complexity would be O(N*logN), because under the hood it uses binary
search.
The comment you've mentioned says that you can traverse your CPUs in
O(N) if you can manage to put all the logic inside the
for_each_numa_hop_mask() iterator. It doesn't seem to be your case.
I agree with you. mlx5_cpumask_default_spread() should be switched to
using library code.
Acked-by: Yury Norov <yury.norov@gmail.com>
You may be interested in siblings-aware CPU distribution I've made
for mana ethernet driver in 91bfe210e196. This is also an example
where using for_each_numa_hop_mask() over simple cpumask_local_spread()
is justified.
Thanks,
Yury
next prev parent reply other threads:[~2024-08-14 14:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 8:22 [PATCH] net/mlx5: Use cpumask_local_spread() instead of custom code Erwan Velu
2024-08-14 7:48 ` Tariq Toukan
2024-08-14 14:45 ` Yury Norov [this message]
2024-08-15 10:39 ` Tariq Toukan
2024-08-19 10:15 ` Erwan Velu
2024-08-19 15:34 ` Jakub Kicinski
2024-08-19 15:41 ` Erwan Velu
2024-08-16 2:10 ` patchwork-bot+netdevbpf
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=ZrzDAlMiEK4fnLmn@yury-ThinkPad \
--to=yury.norov@gmail.com \
--cc=davem@davemloft.net \
--cc=e.velu@criteo.com \
--cc=edumazet@google.com \
--cc=erwanaliasr1@gmail.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=raanand@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=ttoukan.linux@gmail.com \
--cc=ynorov@nvidia.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