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. chris -- Prof. Dr.-Ing. Christian Dietrich Operating System Group (E-EXK4) Technische Universität Hamburg Am Schwarzenberg-Campus 3 (E) 21073 Hamburg eMail: christian.dietrich@xxxxxxx Tel: +49 40 42878 2188 WWW: https://osg.tuhh.de/
