From: Jason Gunthorpe <jgg@nvidia.com>
To: Li Zhijian <lizhijian@fujitsu.com>
Cc: Bob Pearson <rpearsonhpe@gmail.com>,
Leon Romanovsky <leon@kernel.org>,
linux-rdma@vger.kernel.org, Zhu Yanjun <zyjzyj2000@gmail.com>,
yangx.jy@fujitsu.com, y-goto@fujitsu.com, mbloch@nvidia.com,
liangwenpeng@huawei.com, tom@talpey.com,
tomasz.gromadzki@intel.com, dan.j.williams@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [for-next PATCH v5 05/11] RDMA/rxe: Allow registering persistent flag for pmem MR only
Date: Fri, 28 Oct 2022 14:53:19 -0300 [thread overview]
Message-ID: <Y1wXD/cnIlGUANBY@nvidia.com> (raw)
In-Reply-To: <20220927055337.22630-6-lizhijian@fujitsu.com>
On Tue, Sep 27, 2022 at 01:53:31PM +0800, Li Zhijian wrote:
> @@ -122,6 +129,7 @@ int rxe_mr_init_user(struct rxe_dev *rxe, u64 start, u64 length, u64 iova,
> int num_buf;
> void *vaddr;
> int err;
> + bool is_pmem = false;
> int i;
>
> umem = ib_umem_get(&rxe->ib_dev, start, length, access);
> @@ -149,6 +157,7 @@ int rxe_mr_init_user(struct rxe_dev *rxe, u64 start, u64 length, u64 iova,
> num_buf = 0;
> map = mr->map;
> if (length > 0) {
> + is_pmem = true;
> buf = map[0]->buf;
>
> for_each_sgtable_page (&umem->sgt_append.sgt, &sg_iter, 0) {
> @@ -166,6 +175,10 @@ int rxe_mr_init_user(struct rxe_dev *rxe, u64 start, u64 length, u64 iova,
> goto err_cleanup_map;
> }
>
> + /* True only if the *whole* MR is pmem */
> + if (is_pmem)
> + is_pmem = vaddr_in_pmem(vaddr);
> +
I'm not so keen on this use of resources, but this should be written more
like
phys = page_to_phys(sg_page_iter_page(&sg_iter))
region_intersects(phys + sg_iter->offset, sg_iter->length,.. )
And you understand this will make memory registration of every RXE
user a bit slower? And actual pmem will be painfully slow.
It seems like we are doing something wrong here..
> @@ -174,6 +187,12 @@ int rxe_mr_init_user(struct rxe_dev *rxe, u64 start, u64 length, u64 iova,
> }
> }
>
> + if (!is_pmem && access & IB_ACCESS_FLUSH_PERSISTENT) {
> + pr_warn("Cannot register IB_ACCESS_FLUSH_PERSISTENT for non-pmem memory\n");
> + err = -EINVAL;
> + goto err_release_umem;
> + }
Do not pr_warn on syscall paths
Jason
next prev parent reply other threads:[~2022-10-28 17:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 5:53 [for-next PATCH v5 00/11] RDMA/rxe: Add RDMA FLUSH operation Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 01/11] RDMA/rxe: make sure requested access is a subset of {mr,mw}->access Li Zhijian
2022-10-28 17:45 ` Jason Gunthorpe
2022-09-27 5:53 ` [for-next PATCH v5 02/11] RDMA: Extend RDMA user ABI to support flush Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 03/11] RDMA: Extend RDMA kernel verbs " Li Zhijian
2022-09-29 6:21 ` Li Zhijian
2022-09-30 18:04 ` Jason Gunthorpe
2022-10-28 17:44 ` Jason Gunthorpe
2022-10-29 3:15 ` Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 04/11] RDMA/rxe: Extend rxe user " Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 05/11] RDMA/rxe: Allow registering persistent flag for pmem MR only Li Zhijian
2022-10-28 17:53 ` Jason Gunthorpe [this message]
2022-10-30 3:33 ` Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 06/11] RDMA/rxe: Extend rxe packet format to support flush Li Zhijian
2022-11-11 8:43 ` Yanjun Zhu
2022-11-11 8:55 ` lizhijian
2022-11-11 9:28 ` Yanjun Zhu
2022-09-27 5:53 ` [for-next PATCH v5 07/11] RDMA/rxe: Implement RC RDMA FLUSH service in requester side Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 08/11] RDMA/rxe: Implement flush execution in responder side Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 09/11] RDMA/rxe: Implement flush completion Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 10/11] RDMA/cm: Make QP FLUSHABLE Li Zhijian
2022-09-27 5:53 ` [for-next PATCH v5 11/11] RDMA/rxe: Enable RDMA FLUSH capability for rxe device Li Zhijian
2022-10-28 17:44 ` [for-next PATCH v5 00/11] RDMA/rxe: Add RDMA FLUSH operation Jason Gunthorpe
2022-10-28 17:57 ` Jason Gunthorpe
2022-11-11 2:49 ` Yanjun Zhu
2022-11-11 5:10 ` lizhijian
2022-11-11 5:52 ` Yanjun Zhu
2022-11-11 6:10 ` lizhijian
2022-11-11 6:30 ` Yanjun Zhu
2022-11-11 6:38 ` lizhijian
2022-11-11 7:08 ` Yanjun Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1wXD/cnIlGUANBY@nvidia.com \
--to=jgg@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=leon@kernel.org \
--cc=liangwenpeng@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=mbloch@nvidia.com \
--cc=rpearsonhpe@gmail.com \
--cc=tom@talpey.com \
--cc=tomasz.gromadzki@intel.com \
--cc=y-goto@fujitsu.com \
--cc=yangx.jy@fujitsu.com \
--cc=zyjzyj2000@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.