Re: [RFC PATCH 0/2] io_uring: add IPC channel infrastructure

[Daniel Hodges]

On Mon, Mar 16, 2026 at 07:13:42PM -0400, Daniel Hodges wrote:
> On Mon, Mar 16, 2026 at 04:17:05PM -0600, Jens Axboe wrote:
> > On 3/16/26 6:49 AM, Daniel Hodges wrote:
> > > On Sat, Mar 14, 2026 at 10:54:15AM -0600, Jens Axboe wrote:
> > >> On 3/14/26 7:50 AM, Daniel Hodges wrote:
> > >>> On Thu, Mar 13, 2026 at 01:07:37PM +0000, Daniel Hodges wrote:
> > >>>> Performance (virtme-ng VM, single-socket, msg_size sweep 64B-32KB):
> > >>>>
> > >>>>   Point-to-point latency (64B-32KB messages):
> > >>>>     io_uring unicast: 597-3,185 ns/msg (within 1.5-2.5x of pipe for small msgs)
> > >>>
> > >>> Benchmark sources used to generate the numbers in the cover letter:
> > >>>
> > >>>   io_uring IPC modes (broadcast, multicast, unicast):
> > >>>     https://gist.github.com/hodgesds/fbcd8bb8497bc0ec2bf1f95244a984fe#file-io_uring_ipc_bench-c
> > >>>
> > >>>   IPC comparison (pipes, unix sockets, shm+eventfd):
> > >>>     https://gist.github.com/hodgesds/fbcd8bb8497bc0ec2bf1f95244a984fe#file-ipc_comparison_bench-c
> > >>
> > >> Thanks for sending these, was going to ask you about them. I'll take a
> > >> look at your patches Monday.
> > >>
> > >> -- 
> > >> Jens Axboe
> > > 
> > > No rush, thanks for taking the time!
> > 
> > I took a look - and I think it's quite apparent that it's a AI vibe
> > coded patch. Hence my first question is, do you have a specific use case
> > in mind? Or phrased differently, was this done for a specific use case
> > you have and want to pursue, or was it more of a "let's see if we can do
> > this and what it'd look like" kind of thing?
> > 
> > I have a lot of comments on the patch itself, but let's establish the
> > motivation here first.
> > 
> > -- 
> > Jens Axboe
> 
> I've been helping Alexandre prototype a D-Bus broker replacement that
> scales better on large machines. Here's some docs/benchmarks:
> https://github.com/fiorix/sbus/blob/main/sbus-broker/docs/analysis.md
> 
> The idea for this RFC by trying to come up with a design if D-Bus was to
> be built from the ground so that it could scale on large machines. D-Bus
> was built because the kernel never really had a broadcast/multicast
> solution for IPC and kdbus demonstrated that moving dbus into the kernel
> wasn't viable either. So that's where I sort of landed on the idea of
> what if io_uring could be used for this type of IPC.
> 
> There isn't a working io_uring backed D-Bus implementation yet as
> it would require features that aren't in this patch such a handling
> credentials etc. I fully acknowledge I had AI help in working on this,
> but if this idea make sense I would appreciate some human direction. If
> it seems like it could be feasible from your pespective I would like to
> try to give it a proper attempt. Thanks!
> 
> -Daniel

I just realized the link I sent is private, here's a link to the D-Bus broker
docs/benchmarks from my fork:
https://github.com/hodgesds/dbus-rust/blob/main/sbus-broker/docs/analysis.md