On 11/6/24 6:22 PM, Ming Lei wrote: > On Wed, Nov 06, 2024 at 08:15:13AM -0700, Jens Axboe wrote: >> On 11/6/24 5:26 AM, Ming Lei wrote: >>> Prepare for supporting kernel buffer in case of io group, in which group >>> leader leases kernel buffer to io_uring, and consumed by io_uring OPs. >>> >>> So reuse io_mapped_buf for group kernel buffer, and unfortunately >>> io_import_fixed() can't be reused since userspace fixed buffer is >>> virt-contiguous, but it isn't true for kernel buffer. >>> >>> Also kernel buffer lifetime is bound with group leader request, it isn't >>> necessary to use rsrc_node for tracking its lifetime, especially it needs >>> extra allocation of rsrc_node for each IO. >> >> While it isn't strictly necessary, I do think it'd clean up the io_kiocb >> parts and hopefully unify the assign and put path more. So I'd strongly >> suggest you do use an io_rsrc_node, even if it does just map the >> io_mapped_buf for this. > > Can you share your idea about how to unify buffer? I am also interested > in this area, so I may take it into account in this patch. I just mean use an io_rsrc_node rather than an io_mapped_buf. The node holds the buf, and then it should not need extra checking. Particularly with the callback, which I think needs to go in the io_rsrc_node. Hence I don't think you need to change much. Yes your mapping side will need to allocate an io_rsrc_node for this, but that's really not too bad. The benefits would be that the node assignment to an io_kiocb and putting of the node would follow normal registered buffers. > Will you plan to use io_rsrc_node for all buffer type(include buffer > select)? Probably not - the provided ring buffers are very low overhead and shared between userspace and the kernel, so it would not make much sense to shove an io_rsrc_node in between. But for anything else, yeah I'd love to see it just use the resource node. -- Jens Axboe
