On 4/29/22 12:31 PM, Hao Xu wrote: > On 4/27/22 09:54, Jens Axboe wrote: >> Hi, >> >> I had a re-think on the flags2 addition [1] that was posted earlier >> today, and I don't really like the fact that flags2 then can't work >> with ioprio for read/write etc. We might also want to extend the >> ioprio field for other types of IO in the future. >> >> So rather than do that, do a simpler approach and just add an io_uring >> specific flag set for send/recv and friends. This then allow setting >> IORING_RECVSEND_POLL_FIRST in sqe->addr2 for those, and if set, io_uring >> will arm poll first rather than attempt a send/recv operation. >> >> [1] https://lore.kernel.org/io-uring/20220426183343.150273-1-axboe@xxxxxxxxx/ >> > > Hi Jens, > Could we use something like the high bits of sqe->fd to store general > flags2 since I saw the number of open FDs can be about (1<<20) at > most. Though I'm not sure if we can assume the limitation of fd won't > change in the future.. I think that's a bit iffy, it's pretty universally true (at least on *NIX) that and fd is a signed int. So I'd be hesitant to do that. I don't mind the flags here, generally we have potentially 3 per request: - SQE specific ones, these are the IOSQE_* flags and are meant to be generally applicable to all/most commands. io_uring internal, have no meaning outside of io_uring. - Some requests are layered on top of existing functionality, the recv/recvmsg is a good example. They have their own sets of flags. We generally use the sqe->rw_flags space for those. - Lastly, io_uring modifiers to specific requests. That's what this patch adds. They don't make sense to the lower layers, but they are specific to this request type for io_uring. The 3rd type is put in sqe->rw_flags for io_uring specific opcodes, but for commands that already have flags in the 2nd category, we have to put them somewhere else. Not a big deal imho, at least as long as the request type has space in the sqe for it. They generally do, they did in this case. -- Jens Axboe
