From: Alice Ryhl <aliceryhl@google.com>
To: Marco Crivellari <marco.crivellari@suse.com>
Cc: Boqun Feng <boqun.feng@gmail.com>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
Lai Jiangshan <jiangshanlai@gmail.com>,
Frederic Weisbecker <frederic@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Michal Hocko <mhocko@suse.com>, Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>
Subject: Re: [PATCH v3 2/2] rust: add system_percpu() around the new system_percpu_wq
Date: Mon, 12 Jan 2026 09:05:38 +0000 [thread overview]
Message-ID: <aWS5Yg9xScOR51Q1@google.com> (raw)
In-Reply-To: <CAAofZF76TADGfF36gMV7qpZCHpXUYY+aOi_mFwrE6UrnkkQKXg@mail.gmail.com>
On Fri, Jan 09, 2026 at 05:32:23PM +0100, Marco Crivellari wrote:
> On Thu, Oct 9, 2025 at 1:17 PM Alice Ryhl <aliceryhl@google.com> wrote:
> > [...]
> > > If we were to expose the system_percpu_wq to Rust, then we should also
> > > add queue_work_on() API to Rust, otherwise it's kinda pointless IMO.
> > >
> > > PS. We can use the CpuId abstraction:
> > >
> > > http://rust.docs.kernel.org/kernel/cpu/struct.CpuId.html
> > >
> > > and have an API like:
> > >
> > > ipml Queue {
> > > pub fn queue_on(&self, cpu: CpuId, w: W) -> W::EqueueOutput
> > > }
> > >
> > > or maybe a different new type `PerCpuQueue`?
> > >
> > > Regards,
> > > Boqun
> >
> > How is it ... can we cleanly separate queues into those where you must
> > specify the cpuid, and those where you shouldn't?
>
> Hi,
>
> Sorry to come back to you so late. I still had many other subsystems patches,
> now there are way less, many of them are accepted.
>
> Can I have some guidance about this? I am new to Rust.
> What's the best way in order to expose the workqueues?
>
> If I understand correctly, the Idea is extends the functionalities of:
>
> https://rust.docs.kernel.org/kernel/workqueue/struct.Queue.html
>
> adding the "queue_on" function.
>
> Creating a new type like "PerCpuQueue" I guess it means... wraps always
> the workqueue_struct structure and defines what's appropriate, like the
> new per-cpu workqueue.
>
> Many thanks in advance!
Yes, we can provide a new `struct PerCpuQueue` with same contents as
`Queue`, where the `enqueue` and `enqueue_delayed` methods take a cpu id
parameter.
Then, all of the functions for obtaining queues at the bottom of the
file are updated to return &PerCpuQueue instead of &Queue when a cpu id
sone option here is tohould be provided to spawn on that queue.
This way, you write:
workqueue::system().enqueue(my_work_item)
or you write:
workqueue::system_percpu().enqueue(my_work_item, cpu_id)
This way you must supply cpu id with system_percpu_wq() but not with
system().
--
Another approach is to add a new `enqueue_cpu` to the existing `Queue`
struct. In that case, all of these four combinations become legal:
workqueue::system().enqueue(my_work_item)
workqueue::system().enqueue_cpu(my_work_item, cpu_id)
workqueue::system_percpu().enqueue(my_work_item)
workqueue::system_percpu().enqueue_cpu(my_work_item, cpu_id)
which approach is best depends on whether you want all four combinations
to be legal or not.
Alice
next prev parent reply other threads:[~2026-01-12 9:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 15:15 [PATCH v3 0/2] rust: add new workqueue functions Marco Crivellari
2025-10-08 15:15 ` [PATCH v3 1/2] rust: add system_dfl() around the new system_dfl_wq Marco Crivellari
2025-10-08 15:15 ` [PATCH v3 2/2] rust: add system_percpu() around the new system_percpu_wq Marco Crivellari
2025-10-08 15:56 ` Boqun Feng
2025-10-09 11:17 ` Alice Ryhl
2026-01-09 16:32 ` Marco Crivellari
2026-01-12 9:05 ` Alice Ryhl [this message]
2026-01-12 16:10 ` Marco Crivellari
2026-01-12 16:22 ` Alice Ryhl
2026-01-26 15:45 ` Marco Crivellari
2026-02-03 8:41 ` Marco Crivellari
2026-02-03 10:19 ` Alice Ryhl
2025-10-08 16:20 ` Miguel Ojeda
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=aWS5Yg9xScOR51Q1@google.com \
--to=aliceryhl@google.com \
--cc=alex.gaynor@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=mhocko@suse.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--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.