On 5/5/21 5:13 PM, Christian Dietrich wrote: > Christian Dietrich <stettberger@xxxxxxxxxxx> [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
