Re: [RFC] Programming model for io_uring + eBPF

[Pavel Begunkov <asml.silence@gmail.com>]

On 5/5/21 5:13 PM, Christian Dietrich wrote:
> Christian Dietrich <stettberger@dokucode.de> [05. May 2021]:
> 
>> So perhaps, we would do something like
>>
>>     // alloc 3 groups
>>     io_uring_register(fd, REGISTER_SYNCHRONIZATION_GROUPS, 3);
>>
>>     // submit a synchronized SQE
>>     sqe->flags |= IOSQE_SYNCHRONIZE;
>>     sqe->synchronize_group = 1;     // could probably be restricted to uint8_t.
>>
>> When looking at this, this could generally be a nice feature to have
>> with SQEs, or? Hereby, the user could insert all of his SQEs and they
>> would run sequentially. In contrast to SQE linking, the order of SQEs
>> would not be determined, which might be beneficial at some point.
> 
> I was thinking further about this statement: "Performing (optional)
> serialization of eBPF-SQEs is similar to SQE linking".
> 
> If we would want to implement the above interface of synchronization
> groups, it could be done without taking locks but by fixing the
> execution order at submit time. Thereby, synchronization groups would
> become a form of "implicit SQE linking".
> 
> The following SQE would become: Append this SQE to the SQE-link chain
> with the name '1'. If the link chain has completed, start a new one.
> Thereby, the user could add an SQE to an existing link chain, even other
> SQEs are already submitted.
> 
>>     sqe->flags |= IOSQE_SYNCHRONIZE;
>>     sqe->synchronize_group = 1;     // could probably be restricted to uint8_t.
> 
> Implementation wise, we would hold a pointer to the last element of the
> implicitly generated link chain.
Such things go really horribly with performant APIs as io_uring, even
if not used. Just see IOSQE_IO_DRAIN, it maybe almost never used but
still in the hot path.

-- 
Pavel Begunkov