This patche series introduce io_uring_cmd_import_vec. With this function,
Multiple fixed buffer could be used in uring cmd. It's vectored version
for io_uring_cmd_import_fixed(). Also this patch series includes a usage
for new api for encoded read in btrfs by using uring cmd.

Sorry for mis-sending noisy mails.

v2:
 - don't export iou_vc, use bvec for btrfs
 - use io_is_compat for checking compat
 - reduce allocation/free for import fixed vec
 
Sidong Yang (2):
  io_uring: cmd: introduce io_uring_cmd_import_fixed_vec
  btrfs: ioctl: use registered buffer for IORING_URING_CMD_FIXED

 fs/btrfs/ioctl.c             | 27 ++++++++++++++++++++++-----
 include/linux/io_uring/cmd.h | 14 ++++++++++++++
 io_uring/uring_cmd.c         | 31 +++++++++++++++++++++++++++++++
 3 files changed, 67 insertions(+), 5 deletions(-)

--
2.43.0

On 3/12/25 14:23, Sidong Yang wrote:
> This patche series introduce io_uring_cmd_import_vec. With this function,
> Multiple fixed buffer could be used in uring cmd. It's vectored version
> for io_uring_cmd_import_fixed(). Also this patch series includes a usage
> for new api for encoded read in btrfs by using uring cmd.

Pretty much same thing, we're still left with 2 allocations in the
hot path. What I think we can do here is to add caching on the
io_uring side as we do with rw / net, but that would be invisible
for cmd drivers. And that cache can be reused for normal iovec imports.

https://github.com/isilence/linux.git regvec-import-cmd
(link for convenience)
https://github.com/isilence/linux/tree/regvec-import-cmd

Not really target tested, no btrfs, not any other user, just an idea.
There are 4 patches, but the top 3 are of interest.

Another way would be to cache in btrfs, but then btrfs would need to
care about locking for the cache and some other bits, and we wouldn't
be able to reuse it for other drivers.

-- 
Pavel Begunkov

On Thu, Mar 13, 2025 at 08:57:45AM +0000, Pavel Begunkov wrote:
> On 3/12/25 14:23, Sidong Yang wrote:
> > This patche series introduce io_uring_cmd_import_vec. With this function,
> > Multiple fixed buffer could be used in uring cmd. It's vectored version
> > for io_uring_cmd_import_fixed(). Also this patch series includes a usage
> > for new api for encoded read in btrfs by using uring cmd.
> 
> Pretty much same thing, we're still left with 2 allocations in the
> hot path. What I think we can do here is to add caching on the
> io_uring side as we do with rw / net, but that would be invisible
> for cmd drivers. And that cache can be reused for normal iovec imports.
> 
> https://github.com/isilence/linux.git regvec-import-cmd
> (link for convenience)
> https://github.com/isilence/linux/tree/regvec-import-cmd
> 
> Not really target tested, no btrfs, not any other user, just an idea.
> There are 4 patches, but the top 3 are of interest.

Thanks, I justed checked the commits now. I think cache is good to resolve
this without allocation if cache hit. Let me reimpl this idea and test it
for btrfs.

> 
> Another way would be to cache in btrfs, but then btrfs would need to
> care about locking for the cache and some other bits, and we wouldn't
> be able to reuse it for other drivers.

Agreed, it could be better to reuse it for other driver.

Thanks,
Sidong
> 
> -- 
> Pavel Begunkov
>

On 3/13/25 10:44, Sidong Yang wrote:
> On Thu, Mar 13, 2025 at 08:57:45AM +0000, Pavel Begunkov wrote:
>> On 3/12/25 14:23, Sidong Yang wrote:
>>> This patche series introduce io_uring_cmd_import_vec. With this function,
>>> Multiple fixed buffer could be used in uring cmd. It's vectored version
>>> for io_uring_cmd_import_fixed(). Also this patch series includes a usage
>>> for new api for encoded read in btrfs by using uring cmd.
>>
>> Pretty much same thing, we're still left with 2 allocations in the
>> hot path. What I think we can do here is to add caching on the
>> io_uring side as we do with rw / net, but that would be invisible
>> for cmd drivers. And that cache can be reused for normal iovec imports.
>>
>> https://github.com/isilence/linux.git regvec-import-cmd
>> (link for convenience)
>> https://github.com/isilence/linux/tree/regvec-import-cmd
>>
>> Not really target tested, no btrfs, not any other user, just an idea.
>> There are 4 patches, but the top 3 are of interest.
> 
> Thanks, I justed checked the commits now. I think cache is good to resolve
> this without allocation if cache hit. Let me reimpl this idea and test it
> for btrfs.

Sure, you can just base on top of that branch, hashes might be
different but it's identical to the base it should be on. Your
v2 didn't have some more recent merged patches.

-- 
Pavel Begunkov

On 3/13/25 13:15, Pavel Begunkov wrote:
> On 3/13/25 10:44, Sidong Yang wrote:
>> On Thu, Mar 13, 2025 at 08:57:45AM +0000, Pavel Begunkov wrote:
>>> On 3/12/25 14:23, Sidong Yang wrote:
>>>> This patche series introduce io_uring_cmd_import_vec. With this function,
>>>> Multiple fixed buffer could be used in uring cmd. It's vectored version
>>>> for io_uring_cmd_import_fixed(). Also this patch series includes a usage
>>>> for new api for encoded read in btrfs by using uring cmd.
>>>
>>> Pretty much same thing, we're still left with 2 allocations in the
>>> hot path. What I think we can do here is to add caching on the
>>> io_uring side as we do with rw / net, but that would be invisible
>>> for cmd drivers. And that cache can be reused for normal iovec imports.
>>>
>>> https://github.com/isilence/linux.git regvec-import-cmd
>>> (link for convenience)
>>> https://github.com/isilence/linux/tree/regvec-import-cmd
>>>
>>> Not really target tested, no btrfs, not any other user, just an idea.
>>> There are 4 patches, but the top 3 are of interest.
>>
>> Thanks, I justed checked the commits now. I think cache is good to resolve
>> this without allocation if cache hit. Let me reimpl this idea and test it
>> for btrfs.
> 
> Sure, you can just base on top of that branch, hashes might be
> different but it's identical to the base it should be on. Your
> v2 didn't have some more recent merged patches.

Jens' for-6.15/io_uring-reg-vec specifically, but for-next likely
has it merged.

-- 
Pavel Begunkov

On Thu, Mar 13, 2025 at 01:17:44PM +0000, Pavel Begunkov wrote:
> On 3/13/25 13:15, Pavel Begunkov wrote:
> > On 3/13/25 10:44, Sidong Yang wrote:
> > > On Thu, Mar 13, 2025 at 08:57:45AM +0000, Pavel Begunkov wrote:
> > > > On 3/12/25 14:23, Sidong Yang wrote:
> > > > > This patche series introduce io_uring_cmd_import_vec. With this function,
> > > > > Multiple fixed buffer could be used in uring cmd. It's vectored version
> > > > > for io_uring_cmd_import_fixed(). Also this patch series includes a usage
> > > > > for new api for encoded read in btrfs by using uring cmd.
> > > > 
> > > > Pretty much same thing, we're still left with 2 allocations in the
> > > > hot path. What I think we can do here is to add caching on the
> > > > io_uring side as we do with rw / net, but that would be invisible
> > > > for cmd drivers. And that cache can be reused for normal iovec imports.
> > > > 
> > > > https://github.com/isilence/linux.git regvec-import-cmd
> > > > (link for convenience)
> > > > https://github.com/isilence/linux/tree/regvec-import-cmd
> > > > 
> > > > Not really target tested, no btrfs, not any other user, just an idea.
> > > > There are 4 patches, but the top 3 are of interest.
> > > 
> > > Thanks, I justed checked the commits now. I think cache is good to resolve
> > > this without allocation if cache hit. Let me reimpl this idea and test it
> > > for btrfs.
> > 
> > Sure, you can just base on top of that branch, hashes might be
> > different but it's identical to the base it should be on. Your
> > v2 didn't have some more recent merged patches.
> 
> Jens' for-6.15/io_uring-reg-vec specifically, but for-next likely
> has it merged.

Yes, there is commits about io_uring-reg-vec in Jens' for-next. I'll make v3 based
on the branch.

> 
> -- 
> Pavel Begunkov
>

On 3/13/25 7:56 AM, Sidong Yang wrote:
> On Thu, Mar 13, 2025 at 01:17:44PM +0000, Pavel Begunkov wrote:
>> On 3/13/25 13:15, Pavel Begunkov wrote:
>>> On 3/13/25 10:44, Sidong Yang wrote:
>>>> On Thu, Mar 13, 2025 at 08:57:45AM +0000, Pavel Begunkov wrote:
>>>>> On 3/12/25 14:23, Sidong Yang wrote:
>>>>>> This patche series introduce io_uring_cmd_import_vec. With this function,
>>>>>> Multiple fixed buffer could be used in uring cmd. It's vectored version
>>>>>> for io_uring_cmd_import_fixed(). Also this patch series includes a usage
>>>>>> for new api for encoded read in btrfs by using uring cmd.
>>>>>
>>>>> Pretty much same thing, we're still left with 2 allocations in the
>>>>> hot path. What I think we can do here is to add caching on the
>>>>> io_uring side as we do with rw / net, but that would be invisible
>>>>> for cmd drivers. And that cache can be reused for normal iovec imports.
>>>>>
>>>>> https://github.com/isilence/linux.git regvec-import-cmd
>>>>> (link for convenience)
>>>>> https://github.com/isilence/linux/tree/regvec-import-cmd
>>>>>
>>>>> Not really target tested, no btrfs, not any other user, just an idea.
>>>>> There are 4 patches, but the top 3 are of interest.
>>>>
>>>> Thanks, I justed checked the commits now. I think cache is good to resolve
>>>> this without allocation if cache hit. Let me reimpl this idea and test it
>>>> for btrfs.
>>>
>>> Sure, you can just base on top of that branch, hashes might be
>>> different but it's identical to the base it should be on. Your
>>> v2 didn't have some more recent merged patches.
>>
>> Jens' for-6.15/io_uring-reg-vec specifically, but for-next likely
>> has it merged.
> 
> Yes, there is commits about io_uring-reg-vec in Jens' for-next. I'll
> make v3 based on the branch.

Basing patches on that is fine, just never base branches on it. My
for-next branch is just a merge point for _everything_ that's queued for
the next release, io_uring and block related. The right branch to base
on for this case would be for-6.15/io_uring-reg-vec, which is also in my
for-next branch.

This is more of a FYI than anything, as you're not doing a pull request.
Using for-next for patches is fine.

-- 
Jens Axboe

On Thu, Mar 13, 2025 at 08:01:15AM -0600, Jens Axboe wrote:
> On 3/13/25 7:56 AM, Sidong Yang wrote:
> > On Thu, Mar 13, 2025 at 01:17:44PM +0000, Pavel Begunkov wrote:
> >> On 3/13/25 13:15, Pavel Begunkov wrote:
> >>> On 3/13/25 10:44, Sidong Yang wrote:
> >>>> On Thu, Mar 13, 2025 at 08:57:45AM +0000, Pavel Begunkov wrote:
> >>>>> On 3/12/25 14:23, Sidong Yang wrote:
> >>>>>> This patche series introduce io_uring_cmd_import_vec. With this function,
> >>>>>> Multiple fixed buffer could be used in uring cmd. It's vectored version
> >>>>>> for io_uring_cmd_import_fixed(). Also this patch series includes a usage
> >>>>>> for new api for encoded read in btrfs by using uring cmd.
> >>>>>
> >>>>> Pretty much same thing, we're still left with 2 allocations in the
> >>>>> hot path. What I think we can do here is to add caching on the
> >>>>> io_uring side as we do with rw / net, but that would be invisible
> >>>>> for cmd drivers. And that cache can be reused for normal iovec imports.
> >>>>>
> >>>>> https://github.com/isilence/linux.git regvec-import-cmd
> >>>>> (link for convenience)
> >>>>> https://github.com/isilence/linux/tree/regvec-import-cmd
> >>>>>
> >>>>> Not really target tested, no btrfs, not any other user, just an idea.
> >>>>> There are 4 patches, but the top 3 are of interest.
> >>>>
> >>>> Thanks, I justed checked the commits now. I think cache is good to resolve
> >>>> this without allocation if cache hit. Let me reimpl this idea and test it
> >>>> for btrfs.
> >>>
> >>> Sure, you can just base on top of that branch, hashes might be
> >>> different but it's identical to the base it should be on. Your
> >>> v2 didn't have some more recent merged patches.
> >>
> >> Jens' for-6.15/io_uring-reg-vec specifically, but for-next likely
> >> has it merged.
> > 
> > Yes, there is commits about io_uring-reg-vec in Jens' for-next. I'll
> > make v3 based on the branch.
> 
> Basing patches on that is fine, just never base branches on it. My
> for-next branch is just a merge point for _everything_ that's queued for
> the next release, io_uring and block related. The right branch to base
> on for this case would be for-6.15/io_uring-reg-vec, which is also in my
> for-next branch.

Agreed, for-6.15/io_uring-reg-vec is the right base branch for this. 

Thanks,
Sidong
> 
> This is more of a FYI than anything, as you're not doing a pull request.
> Using for-next for patches is fine.
> 
> -- 
> Jens Axboe