This behaves like IORING_OP_READ, except: 1) It only supports pollable files (eg pipes, sockets, etc). Note that for sockets, you probably want to use recv/recvmsg with multishot instead. 2) It supports multishot mode, meaning it will repeatedly trigger a read and fill a buffer when data is available. This allows similar use to recv/recvmsg but on non-sockets, where a single request will repeatedly post a CQE whenever data is read from it. 3) Because of #2, it must be used with provided buffers. This is uniformly true across any request type that supports multishot and transfers data, with the reason being that it's obviously not possible to pass in a single buffer for the data, as multiple reads may very well trigger before an application has a chance to process previous CQEs and the data passed from them.
Showing the changes to include/uapi (1 of 4 files). Show all
Unified · Split
| @@ -240,6 +240,7 @@ enum io_uring_op { · 239 unmodified lines | |||
| 240 | IORING_OP_URING_CMD, | 240 | IORING_OP_URING_CMD, |
| 241 | IORING_OP_SEND_ZC, | 241 | IORING_OP_SEND_ZC, |
| 242 | IORING_OP_SENDMSG_ZC, | 242 | IORING_OP_SENDMSG_ZC, |
| 243 | IORING_OP_READ_MULTISHOT, | ||
| 243 | 244 | ||
| 244 | /* this goes last, obviously */ | 245 | /* this goes last, obviously */ |
| 245 | IORING_OP_LAST, | 246 | IORING_OP_LAST, |