On 10/10/24 8:30 PM, Ming Lei wrote: > Hi Jens, > > On Thu, Oct 10, 2024 at 01:31:21PM -0600, Jens Axboe wrote: >> Hi, >> >> Discussed this with Pavel, and on his suggestion, I tried prototyping a >> "buffer update" opcode. Basically it works like >> IORING_REGISTER_BUFFERS_UPDATE in that it can update an existing buffer >> registration. But it works as an sqe rather than being a sync opcode. >> >> The idea here is that you could do that upfront, or as part of a chain, >> and have it be generically available, just like any other buffer that >> was registered upfront. You do need an empty table registered first, >> which can just be sparse. And since you can pick the slot it goes into, >> you can rely on that slot afterwards (either as a link, or just the >> following sqe). >> >> Quick'n dirty obviously, but I did write a quick test case too to verify >> that: >> >> 1) It actually works (it seems to) > > It doesn't work for ublk zc since ublk needs to provide one kernel buffer > for fs rw & net send/recv to consume, and the kernel buffer is invisible > to userspace. But __io_register_rsrc_update() only can register userspace > buffer. I'd be surprised if this simple one was enough! In terms of user vs kernel buffer, you could certainly use the same mechanism, and just ensure that buffers are tagged appropriately. I need to think about that a little bit. There are certainly many different ways that can get propagated which would not entail a complicated mechanism. I really like the aspect of having the identifier being the same thing that we already use, and hence not needing to be something new on the side. > Also multiple OPs may consume the buffer concurrently, which can't be > supported by buffer select. Why not? You can certainly have multiple ops using the same registered buffer concurrently right now. -- Jens Axboe
