On Sat, Feb 08, 2025 at 02:16:15PM +0000, Pavel Begunkov wrote: > On 2/8/25 05:44, Ming Lei wrote: > > On Fri, Feb 07, 2025 at 07:06:54AM -0700, Keith Busch wrote: > > > On Fri, Feb 07, 2025 at 11:51:49AM +0800, Ming Lei wrote: > > > > On Mon, Feb 03, 2025 at 07:45:11AM -0800, Keith Busch wrote: > > > > > > > > > > The previous version from Ming can be viewed here: > > > > > > > > > > https://lore.kernel.org/linux-block/20241107110149.890530-1-ming.lei@xxxxxxxxxx/ > > > > > > > > > > Based on the feedback from that thread, the desired io_uring interfaces > > > > > needed to be simpler, and the kernel registered resources need to behave > > > > > more similiar to user registered buffers. > > > > > > > > > > This series introduces a new resource node type, KBUF, which, like the > > > > > BUFFER resource, needs to be installed into an io_uring buf_node table > > > > > in order for the user to access it in a fixed buffer command. The > > > > > new io_uring kernel API provides a way for a user to register a struct > > > > > request's bvec to a specific index, and a way to unregister it. > > > > > > > > > > When the ublk server receives notification of a new command, it must > > > > > first select an index and register the zero copy buffer. It may use that > > > > > index for any number of fixed buffer commands, then it must unregister > > > > > the index when it's done. This can all be done in a single io_uring_enter > > > > > if desired, or it can be split into multiple enters if needed. > > > > > > > > I suspect it may not be done in single io_uring_enter() because there > > > > is strict dependency among the three OPs(register buffer, read/write, > > > > unregister buffer). > > > > > > The registration is synchronous. io_uring completes the SQE entirely > > > before it even looks at the read command in the next SQE. > > > > Can you explain a bit "synchronous" here? > > I'd believe synchronous here means "executed during submission from > the submit syscall path". And I agree that we can't rely on that. > That's an implementation detail and io_uring doesn't promise that, The commands are processed in order under the ctx's uring_lock. What are you thinking you might do to make this happen in any different order?
