From: Yury Norov <yury.norov@gmail.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Hannes Reinecke <hare@suse.de>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>
Subject: Re: [PATCH] scsi/fcoe: simplify fcoe_select_cpu()
Date: Wed, 4 Jun 2025 20:35:42 -0400 [thread overview]
Message-ID: <aEDmXvKAvJfjMrCk@yury> (raw)
In-Reply-To: <0959d3c2-b849-4826-8edf-d72a89fbadff@acm.org>
+ Tejun, Lai
On Thu, Jun 05, 2025 at 08:13:53AM +0800, Bart Van Assche wrote:
> On 6/5/25 7:42 AM, Yury Norov wrote:
> > diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
> > index b911fdb387f3..07eddafe52ff 100644
> > --- a/drivers/scsi/fcoe/fcoe.c
> > +++ b/drivers/scsi/fcoe/fcoe.c
> > @@ -1312,10 +1312,7 @@ static inline unsigned int fcoe_select_cpu(void)
> > {
> > static unsigned int selected_cpu;
> > - selected_cpu = cpumask_next(selected_cpu, cpu_online_mask);
> > - if (selected_cpu >= nr_cpu_ids)
> > - selected_cpu = cpumask_first(cpu_online_mask);
> > -
> > + selected_cpu = cpumask_next_wrap(selected_cpu, cpu_online_mask);
> > return selected_cpu;
> > }
>
> Why does this algorithm occur in the FCoE driver? Isn't
> WORK_CPU_UNBOUND good enough for this driver? And if it isn't
> good enough, shouldn't this kind of functionality be integrated in
> kernel/workqueue.c rather than having the above algorithm in a
> kernel driver?
(I'm obviously not an expert in this driver, and just wanted to cleanup
the cpumask API usage.)
It looks like the intention is to distribute the workload among CPUs
sequentially. If you move this function out of the driver, someone
else may call the function, and sequential distribution may get
broken.
If sequential distribution doesn't matter here, and the real
intention is just to distribute workload more or less evenly,
we already have cpumask_any_distribute() for this.
Thanks,
Yury
next prev parent reply other threads:[~2025-06-05 0:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 23:42 [PATCH] scsi/fcoe: simplify fcoe_select_cpu() Yury Norov
2025-06-05 0:13 ` Bart Van Assche
2025-06-05 0:35 ` Yury Norov [this message]
2025-06-05 6:01 ` Hannes Reinecke
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=aEDmXvKAvJfjMrCk@yury \
--to=yury.norov@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.