On 8/16/20 2:09 PM, Josef wrote: >> 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 Gotcha, yes for that case it can be useful. -- Jens Axboe
