On 01/02/2020 12:18, Andres Freund wrote: > Hi, > > Reading the manpage from liburing I read: > IOSQE_IO_LINK > When this flag is specified, it forms a link with the next SQE in the submission ring. That next SQE > will not be started before this one completes. This, in effect, forms a chain of SQEs, which can be > arbitrarily long. The tail of the chain is denoted by the first SQE that does not have this flag set. > This flag has no effect on previous SQE submissions, nor does it impact SQEs that are outside of the > chain tail. This means that multiple chains can be executing in parallel, or chains and individual > SQEs. Only members inside the chain are serialized. Available since 5.3. > > IOSQE_IO_HARDLINK > Like IOSQE_IO_LINK, but it doesn't sever regardless of the completion result. Note that the link will > still sever if we fail submitting the parent request, hard links are only resilient in the presence of > completion results for requests that did submit correctly. IOSQE_IO_HARDLINK implies IOSQE_IO_LINK. > Available since 5.5. > > I can make some sense out of that description of IOSQE_IO_LINK without > looking at kernel code. But I don't think it's possible to understand > what happens when an earlier chain member fails, and what denotes an > error. IOSQE_IO_HARDLINK's description kind of implies that > IOSQE_IO_LINK will not start the next request if there was a failure, > but doesn't define failure either. > Right, after a "failure" occurred for a IOSQE_IO_LINK request, all subsequent requests in the link won't be executed, but completed with -ECANCELED. However, if IOSQE_IO_HARDLINK set for the request, it won't sever/break the link and will continue to the next one. > Looks like it's defined in a somewhat adhoc manner. For file read/write > subsequent requests are failed if they are a short read/write. But > e.g. for sendmsg that looks not to be the case. > As you said, it's defined rather sporadically. We should unify for it to make sense. I'd prefer to follow the read/write pattern. > Perhaps it'd make sense to reject use of IOSQE_IO_LINK outside ops where > it's meaningful? If we disregard it for either length-based operations or the rest ones (or whatever combination), the feature won't be flexible enough to be useful, but in combination it allows to remove much of context switches. -- Pavel Begunkov
Attachment:
signature.asc
Description: OpenPGP digital signature
