Re: bug with fastpoll accept and sqpoll + IOSQE_FIXED_FILE

[Victor Stewart <v@nametag.social>]

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.