> BTW, something I think you're aware of, but wanted to bring up > explicitly - if IORING_FEAT_FAST_POLL is available in the ring features, > then you generally don't want/need to link potentially blocking requests > on pollable files with a poll in front. io_uring will do this > internally, and save you an sqe and completion event for each of these > types of requests. > > Your test case is a perfect example of that, neither the accept nor the > socket read would need a poll linked in front of them, as they are both > pollable file types and will not trigger use of an async thread to wait > for the event. Instead an internal poll is armed which will trigger the > issue of that request, when the socket is ready. I agree as well I don't need a poll linked in font of read event, but not for the non blocking accept event because of this fix in Linux 5.8: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.8&id=e697deed834de15d2322d0619d51893022c90ea2 I receive an immediate response to tell if there's ever any data there, same behaviour like accept non blocking socket, that’s why I use poll link to avoid that -- Josef Grieb
