On 17/08/2020 11:58, 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 am guessing if the socket(non blocking) is not writable as you said > it's a pollable file type, io_uring will first use an internal poll to > check if the socket is writable, right? so I don't explicitly need a > poll(POLLOUT) IIRC, it won't. E.g. one possible scenario: 1. io_issue_sqe(force_nonblock=true), aka inlined execution 2. io_send() sets REQ_F_NOWAIT 3. __io_queue_sqe() fails such request. BTW, Jens, it's not really clear to me, what semantics is expected from io_uring when *NOWAIT is set (e.g. MSG_DONTWAIT)? If that's fail-fast, then it doesn't look consistent that io_wq_submit_work() keeps resubmitting it in a loop. -- Pavel Begunkov
