side note question on optimal sqpoll topology, assume a single threaded application, if you're going to pin the application thread and the sqpoll thread to the same logical cpu... is that stupid? maybe they'll just back and forth preempt each other? because either your application is doing work, or you're waiting on io_uring in the kernel to deliver it more work to do, not a scenario where there's idleness to be exploited with parallelism. the only advantage that comes to my mind would be, take a network server example, reducing the latency of submitted packets getting out by time sharing the work of pushing those packets out with application work constructing the next ones. On Tue, Feb 2, 2021 at 12:30 PM Victor Stewart <v@nametag.social> wrote: > > > There is a change of behaviour, if IORING_FEAT_EXT_ARG is set it > > won't submit (IIRC, since 5.12) -- it's pretty important for some > > multi-threaded cases. > > > > So... where in particular does it say that? In case your liburing > > is up to date and we forgot to remove such a comment. > > https://github.com/axboe/liburing/blob/c96202546bd9d7420d97bc05e73c7144d0924e8a/src/queue.c#L269 > > "For kernels without IORING_FEAT_EXT_ARG (5.10 and older), if 'ts' is > specified, the application need not call io_uring_submit() before > calling this function, as we will do that on its behalf." > > and I'm using the latest Clear Linux kernel which is 5.10, so that's > why I wasn't submitting.
