Re: [PATCH v6 0/5] io_uring zcrx ifq sharing

[David Wei <dw@davidwei.uk>]

On 2025-11-11 06:40, Pavel Begunkov wrote:
> On 11/8/25 18:14, David Wei wrote:
>> Each ifq is bound to a HW RX queue with no way to share this across
>> multiple rings. It is possible that one ring will not be able to fully
>> saturate an entire HW RX queue due to userspace work. There are two ways
>> to handle more work:
>>
>>    1. Move work to other threads, but have to pay context switch overhead
>>       and cold caches.
>>    2. Add more rings with ifqs, but HW RX queues are a limited resource.
>>
>> This patchset add a way for multiple rings to share the same underlying
>> src ifq that is bound to a HW RX queue. Rings with shared ifqs can issue
>> io_recvzc on zero copy sockets, just like the src ring.
>>
>> Userspace are expected to create rings in separate threads and not
>> processes, such that all rings share the same address space. This is
>> because the sharing and synchronisation of refill rings is purely done
>> in userspace with no kernel involvement e.g. dst rings do not mmap the
>> refill ring. Also, userspace must distribute zero copy sockets steered
>> into the same HW RX queue across rings sharing the ifq.
> 
> I agree it's the simplest way to use it, but cross process sharing
> is a valid use case. I'm sure you can mmap it by guessing offset
> and you can place it into some shared memory otherwise.
> 
> The implementation lgtm. I need to give it a run, but let me
> queue it up with other dependencies.
> 

Yeah there's no reason why shm + mmap wouldn't work cross process with
the right offsets, but I do suspect that it'll be niche with most users
running iou across threads in the same process.

We can add cross process support in the future.