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

[Jens Axboe]

On 3/16/26 5:13 PM, 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!

OK, thanks for the explanation! I do think it makes sense to do, and
starting with the basic mechanism first makes sense. I haven't read your
link yet, but I suppose that had details on what else would be needed
feature wise on top of the base?

-- 
Jens Axboe