| Message ID | 20250312142326.11660-1-sidong.yang@furiosa.ai (mailing list archive) |
|---|---|
| Headers | show |
| Series | introduce io_uring_cmd_import_fixed_vec | expand |
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.
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.
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.
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.