* [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec @ 2025-03-12 14:23 Sidong Yang 2025-03-12 14:23 ` [RFC PATCH v2 1/2] io_uring: cmd: " Sidong Yang ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Sidong Yang @ 2025-03-12 14:23 UTC (permalink / raw) To: Josef Bacik, David Sterba, Jens Axboe, Pavel Begunkov Cc: linux-btrfs, linux-kernel, io-uring, Sidong Yang 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [RFC PATCH v2 1/2] io_uring: cmd: introduce io_uring_cmd_import_fixed_vec 2025-03-12 14:23 [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Sidong Yang @ 2025-03-12 14:23 ` Sidong Yang 2025-03-12 14:23 ` [RFC PATCH v2 2/2] btrfs: ioctl: use registered buffer for IORING_URING_CMD_FIXED Sidong Yang 2025-03-13 8:57 ` [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Pavel Begunkov 2 siblings, 0 replies; 12+ messages in thread From: Sidong Yang @ 2025-03-12 14:23 UTC (permalink / raw) To: Josef Bacik, David Sterba, Jens Axboe, Pavel Begunkov Cc: linux-btrfs, linux-kernel, io-uring, Sidong Yang io_uring_cmd_import_fixed_vec() could be used for using multiple fixed buffer in uring_cmd callback. Signed-off-by: Sidong Yang <[email protected]> --- include/linux/io_uring/cmd.h | 14 ++++++++++++++ io_uring/uring_cmd.c | 31 +++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+) diff --git a/include/linux/io_uring/cmd.h b/include/linux/io_uring/cmd.h index 598cacda4aa3..b0e09c685941 100644 --- a/include/linux/io_uring/cmd.h +++ b/include/linux/io_uring/cmd.h @@ -44,6 +44,12 @@ int io_uring_cmd_import_fixed(u64 ubuf, unsigned long len, int rw, struct io_uring_cmd *ioucmd, unsigned int issue_flags); +int io_uring_cmd_import_fixed_vec(struct io_uring_cmd *ioucmd, + const struct iovec __user *uiovec, + unsigned long nr_segs, int rw, + unsigned int issue_flags, + struct iov_iter *iter, struct bio_vec **bvec); + /* * Completes the request, i.e. posts an io_uring CQE and deallocates @ioucmd * and the corresponding io_uring request. @@ -76,6 +82,14 @@ io_uring_cmd_import_fixed(u64 ubuf, unsigned long len, int rw, { return -EOPNOTSUPP; } +int io_uring_cmd_import_fixed_vec(struct io_uring_cmd *ioucmd, + const struct iovec __user *uiovec, + unsigned long nr_segs, int rw, + unsigned int issue_flags, + struct iov_iter *iter, struct bio_vec **bvec); +{ + return -EOPNOTSUPP; +} static inline void io_uring_cmd_done(struct io_uring_cmd *cmd, ssize_t ret, u64 ret2, unsigned issue_flags) { diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c index de39b602aa82..6bf076f45e6a 100644 --- a/io_uring/uring_cmd.c +++ b/io_uring/uring_cmd.c @@ -1,4 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 +#include "linux/io_uring_types.h" #include <linux/kernel.h> #include <linux/errno.h> #include <linux/file.h> @@ -255,6 +256,36 @@ int io_uring_cmd_import_fixed(u64 ubuf, unsigned long len, int rw, } EXPORT_SYMBOL_GPL(io_uring_cmd_import_fixed); +int io_uring_cmd_import_fixed_vec(struct io_uring_cmd *ioucmd, + const struct iovec __user *uiovec, + unsigned long nr_segs, int rw, + unsigned int issue_flags, + struct iov_iter *iter, struct bio_vec **bvec) +{ + struct io_kiocb *req = cmd_to_io_kiocb(ioucmd); + struct iovec *iov; + int ret; + bool is_compat = io_is_compat(req->ctx); + struct iou_vec iou_vec; + + if (!bvec) + return -EINVAL; + + iov = iovec_from_user(uiovec, nr_segs, 0, NULL, is_compat); + if (IS_ERR(iov)) + return PTR_ERR(iov); + + iou_vec.iovec = iov; + iou_vec.nr = nr_segs; + + ret = io_import_reg_vec(rw, iter, req, &iou_vec, iou_vec.nr, 0, + issue_flags); + + *bvec = iou_vec.bvec; + return ret; +} +EXPORT_SYMBOL_GPL(io_uring_cmd_import_fixed_vec); + void io_uring_cmd_issue_blocking(struct io_uring_cmd *ioucmd) { struct io_kiocb *req = cmd_to_io_kiocb(ioucmd); -- 2.43.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [RFC PATCH v2 2/2] btrfs: ioctl: use registered buffer for IORING_URING_CMD_FIXED 2025-03-12 14:23 [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Sidong Yang 2025-03-12 14:23 ` [RFC PATCH v2 1/2] io_uring: cmd: " Sidong Yang @ 2025-03-12 14:23 ` Sidong Yang 2025-03-13 8:57 ` [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Pavel Begunkov 2 siblings, 0 replies; 12+ messages in thread From: Sidong Yang @ 2025-03-12 14:23 UTC (permalink / raw) To: Josef Bacik, David Sterba, Jens Axboe, Pavel Begunkov Cc: linux-btrfs, linux-kernel, io-uring, Sidong Yang This patch supports IORING_URING_CMD_FIXED flags in io-uring cmd. It means that user provided buf_index in sqe that is registered before submitting requests. In this patch, btrfs_uring_encoded_read() makes iov_iter bvec type by checking the io-uring cmd flag. And there is additional bvec field in btrfs_uring_priv for remaining bvec lifecycle. Signed-off-by: Sidong Yang <[email protected]> --- fs/btrfs/ioctl.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 6c18bad53cd3..7ac5a387ae5d 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -3,6 +3,7 @@ * Copyright (C) 2007 Oracle. All rights reserved. */ +#include "linux/bvec.h" #include <linux/kernel.h> #include <linux/bio.h> #include <linux/file.h> @@ -4644,6 +4645,7 @@ struct btrfs_uring_priv { unsigned long nr_pages; struct kiocb iocb; struct iovec *iov; + struct bio_vec *bvec; struct iov_iter iter; struct extent_state *cached_state; u64 count; @@ -4711,6 +4713,7 @@ static void btrfs_uring_read_finished(struct io_uring_cmd *cmd, unsigned int iss kfree(priv->pages); kfree(priv->iov); + kfree(priv->bvec); kfree(priv); } @@ -4730,7 +4733,8 @@ static int btrfs_uring_read_extent(struct kiocb *iocb, struct iov_iter *iter, struct extent_state *cached_state, u64 disk_bytenr, u64 disk_io_size, size_t count, bool compressed, - struct iovec *iov, struct io_uring_cmd *cmd) + struct iovec *iov, struct io_uring_cmd *cmd, + struct bio_vec *bvec) { struct btrfs_inode *inode = BTRFS_I(file_inode(iocb->ki_filp)); struct extent_io_tree *io_tree = &inode->io_tree; @@ -4767,6 +4771,7 @@ static int btrfs_uring_read_extent(struct kiocb *iocb, struct iov_iter *iter, priv->start = start; priv->lockend = lockend; priv->err = 0; + priv->bvec = bvec; ret = btrfs_encoded_read_regular_fill_pages(inode, disk_bytenr, disk_io_size, pages, priv); @@ -4818,6 +4823,7 @@ static int btrfs_uring_encoded_read(struct io_uring_cmd *cmd, unsigned int issue u64 start, lockend; void __user *sqe_addr; struct btrfs_uring_encoded_data *data = io_uring_cmd_get_async_data(cmd)->op_data; + struct bio_vec *bvec = NULL; if (!capable(CAP_SYS_ADMIN)) { ret = -EPERM; @@ -4875,9 +4881,19 @@ static int btrfs_uring_encoded_read(struct io_uring_cmd *cmd, unsigned int issue } data->iov = data->iovstack; - ret = import_iovec(ITER_DEST, data->args.iov, data->args.iovcnt, - ARRAY_SIZE(data->iovstack), &data->iov, - &data->iter); + + if (cmd && (cmd->flags & IORING_URING_CMD_FIXED)) { + ret = io_uring_cmd_import_fixed_vec( + cmd, data->args.iov, data->args.iovcnt, + ITER_DEST, issue_flags, &data->iter, &bvec); + data->iov = NULL; + } else { + ret = import_iovec(ITER_DEST, data->args.iov, + data->args.iovcnt, + ARRAY_SIZE(data->iovstack), + &data->iov, &data->iter); + } + if (ret < 0) goto out_acct; @@ -4929,13 +4945,14 @@ static int btrfs_uring_encoded_read(struct io_uring_cmd *cmd, unsigned int issue ret = btrfs_uring_read_extent(&kiocb, &data->iter, start, lockend, cached_state, disk_bytenr, disk_io_size, count, data->args.compression, - data->iov, cmd); + data->iov, cmd, bvec); goto out_acct; } out_free: kfree(data->iov); + kfree(bvec); out_acct: if (ret > 0) -- 2.43.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec 2025-03-12 14:23 [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Sidong Yang 2025-03-12 14:23 ` [RFC PATCH v2 1/2] io_uring: cmd: " Sidong Yang 2025-03-12 14:23 ` [RFC PATCH v2 2/2] btrfs: ioctl: use registered buffer for IORING_URING_CMD_FIXED Sidong Yang @ 2025-03-13 8:57 ` Pavel Begunkov 2025-03-13 10:44 ` Sidong Yang 2 siblings, 1 reply; 12+ messages in thread From: Pavel Begunkov @ 2025-03-13 8:57 UTC (permalink / raw) To: Sidong Yang, Josef Bacik, David Sterba, Jens Axboe Cc: linux-btrfs, linux-kernel, io-uring 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec 2025-03-13 8:57 ` [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Pavel Begunkov @ 2025-03-13 10:44 ` Sidong Yang 2025-03-13 13:15 ` Pavel Begunkov 0 siblings, 1 reply; 12+ messages in thread From: Sidong Yang @ 2025-03-13 10:44 UTC (permalink / raw) To: Pavel Begunkov Cc: Josef Bacik, David Sterba, Jens Axboe, linux-btrfs, linux-kernel, io-uring 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec 2025-03-13 10:44 ` Sidong Yang @ 2025-03-13 13:15 ` Pavel Begunkov 2025-03-13 13:17 ` Pavel Begunkov 0 siblings, 1 reply; 12+ messages in thread From: Pavel Begunkov @ 2025-03-13 13:15 UTC (permalink / raw) To: Sidong Yang Cc: Josef Bacik, David Sterba, Jens Axboe, linux-btrfs, linux-kernel, io-uring 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec 2025-03-13 13:15 ` Pavel Begunkov @ 2025-03-13 13:17 ` Pavel Begunkov 2025-03-13 13:56 ` Sidong Yang 0 siblings, 1 reply; 12+ messages in thread From: Pavel Begunkov @ 2025-03-13 13:17 UTC (permalink / raw) To: Sidong Yang Cc: Josef Bacik, David Sterba, Jens Axboe, linux-btrfs, linux-kernel, io-uring 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec 2025-03-13 13:17 ` Pavel Begunkov @ 2025-03-13 13:56 ` Sidong Yang 2025-03-13 14:01 ` Jens Axboe 0 siblings, 1 reply; 12+ messages in thread From: Sidong Yang @ 2025-03-13 13:56 UTC (permalink / raw) To: Pavel Begunkov Cc: Josef Bacik, David Sterba, Jens Axboe, linux-btrfs, linux-kernel, io-uring 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec 2025-03-13 13:56 ` Sidong Yang @ 2025-03-13 14:01 ` Jens Axboe 2025-03-13 14:21 ` Sidong Yang 0 siblings, 1 reply; 12+ messages in thread From: Jens Axboe @ 2025-03-13 14:01 UTC (permalink / raw) To: Sidong Yang, Pavel Begunkov Cc: Josef Bacik, David Sterba, linux-btrfs, linux-kernel, io-uring 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec 2025-03-13 14:01 ` Jens Axboe @ 2025-03-13 14:21 ` Sidong Yang 0 siblings, 0 replies; 12+ messages in thread From: Sidong Yang @ 2025-03-13 14:21 UTC (permalink / raw) To: Jens Axboe Cc: Pavel Begunkov, Josef Bacik, David Sterba, linux-btrfs, linux-kernel, io-uring 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec @ 2025-03-12 13:09 Sidong Yang 0 siblings, 0 replies; 12+ messages in thread From: Sidong Yang @ 2025-03-12 13:09 UTC (permalink / raw) To: Jens Axboe, Pavel Begunkov, Josef Bacik, David Sterba Cc: Sidong Yang, io-uring, linux-kernel, linux-btrfs 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. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec @ 2025-03-12 13:04 Sidong Yang 0 siblings, 0 replies; 12+ messages in thread From: Sidong Yang @ 2025-03-12 13:04 UTC (permalink / raw) To: Jens Axboe, Pavel Begunkov, Josef Bacik, David Sterba Cc: Sidong Yang, io-uring, linux-kernel, linux-btrfs 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. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-03-13 14:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-03-12 14:23 [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Sidong Yang 2025-03-12 14:23 ` [RFC PATCH v2 1/2] io_uring: cmd: " Sidong Yang 2025-03-12 14:23 ` [RFC PATCH v2 2/2] btrfs: ioctl: use registered buffer for IORING_URING_CMD_FIXED Sidong Yang 2025-03-13 8:57 ` [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec Pavel Begunkov 2025-03-13 10:44 ` Sidong Yang 2025-03-13 13:15 ` Pavel Begunkov 2025-03-13 13:17 ` Pavel Begunkov 2025-03-13 13:56 ` Sidong Yang 2025-03-13 14:01 ` Jens Axboe 2025-03-13 14:21 ` Sidong Yang -- strict thread matches above, loose matches on Subject: below -- 2025-03-12 13:09 Sidong Yang 2025-03-12 13:04 Sidong Yang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox