From: "lizhijian@fujitsu.com" <lizhijian@fujitsu.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "zyjzyj2000@gmail.com" <zyjzyj2000@gmail.com>,
"leon@kernel.org" <leon@kernel.org>,
Bob Pearson <rpearsonhpe@gmail.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Mark Bloch <mbloch@nvidia.com>, Tom Talpey <tom@talpey.com>,
"tomasz.gromadzki@intel.com" <tomasz.gromadzki@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
"yangx.jy@fujitsu.com" <yangx.jy@fujitsu.com>,
"Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [for-next PATCH v6 09/10] RDMA/cm: Make QP FLUSHABLE
Date: Mon, 28 Nov 2022 10:23:33 +0000 [thread overview]
Message-ID: <3c84d3ca-88f9-0995-4c0a-2b5dc69670b6@fujitsu.com> (raw)
In-Reply-To: <Y4DOPjDKM64ryuP3@nvidia.com>
On 25/11/2022 22:16, Jason Gunthorpe wrote:
>>>>>> ---
>>>>>> drivers/infiniband/core/cm.c | 3 ++-
>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
>>>>>> index 1f9938a2c475..58837aac980b 100644
>>>>>> --- a/drivers/infiniband/core/cm.c
>>>>>> +++ b/drivers/infiniband/core/cm.c
>>>>>> @@ -4096,7 +4096,8 @@ static int cm_init_qp_init_attr(struct cm_id_private *cm_id_priv,
>>>>>> qp_attr->qp_access_flags = IB_ACCESS_REMOTE_WRITE;
>>>>>> if (cm_id_priv->responder_resources)
>>>>>> qp_attr->qp_access_flags |= IB_ACCESS_REMOTE_READ |
>>>>>> - IB_ACCESS_REMOTE_ATOMIC;
>>>>>> + IB_ACCESS_REMOTE_ATOMIC |
>>>>>> + IB_ACCESS_FLUSHABLE;
>>>>> What is the point of this? Nothing checks IB_ACCESS_FLUSHABLE ?
>> I'm fine to expand it in next version.
> OIC, that is why it escaped grep
>
> But this is back to my original question - why is it OK to do this
> here in CMA? Shouldn't this cause other drivers to refuse to create
> the QP because they don't support the flag?
>
Jason,
My flush example got wrong since V5 where responder side does
qp_access_flags check. so i added this patch.
I also agreed it's a good idea that we should only add this flush flag
to the supported drivers. But i haven't figured out how to achieve it in
current RDMA.
After more digging into rdma-core, i found that this flag can be also
set from usespace by calling ibv_modify_qp().
For server side(responder), ibv_modify_qp() must be called after
rdma_accept(). rdma_accept() inside will modify qp_access_flags
again(rdma_get_request is the first place to modify qp_access_flags).
Back to the original question, IIUC, current rdma-core have no API to
set qp_access_flags during qp creating.
FLUSH operation in responder side will check both mr->access_flags and
qp_access_flags. So unsupported device/driver are not able to do flush
at all though qp_access_flags apply to all drivers.
------------------------------------------
(gdb) bt
#0 __ibv_modify_qp_1_1 (qp=0x40fbf0, attr=0x7fffffffd920, attr_mask=57)
at /home/lizhijian/rdma-core/libibverbs/verbs.c:715
#1 0x00007ffff7faa1db in ucma_init_conn_qp (id_priv=0x40f6d0, qp=0x40fbf0)
at /home/lizhijian/rdma-core/librdmacm/cma.c:1380
#2 0x00007ffff7faada2 in rdma_create_qp_ex (id=0x40f6d0,
attr=0x7fffffffda30)
at /home/lizhijian/rdma-core/librdmacm/cma.c:1676
#3 0x00007ffff7faae94 in rdma_create_qp (id=0x40f6d0, pd=0x407710,
qp_init_attr=0x7fffffffdae0)
at /home/lizhijian/rdma-core/librdmacm/cma.c:1702
#4 0x00007ffff7fab5d3 in rdma_get_request (listen=0x40ede0, id=0x4051a8
<id>)
at /home/lizhijian/rdma-core/librdmacm/cma.c:1883
#5 0x0000000000401af9 in run () at
/home/lizhijian/rdma-core/librdmacm/examples/rdma_flush_server.c:91
#6 0x00000000004021ea in main (argc=7, argv=0x7fffffffe228)
at /home/lizhijian/rdma-core/librdmacm/examples/rdma_flush_server.c:282
(gdb) bt
#0 __ibv_modify_qp_1_1 (qp=0x40fbf0, attr=0x7fffffffd930,
attr_mask=1216897)
at /home/lizhijian/rdma-core/libibverbs/verbs.c:715
#1 0x00007ffff7fa9f16 in ucma_modify_qp_rtr (id=0x40f6d0, resp_res=128
'\200')
at /home/lizhijian/rdma-core/librdmacm/cma.c:1304
#2 0x00007ffff7fab80a in rdma_accept (id=0x40f6d0, conn_param=0x0)
at /home/lizhijian/rdma-core/librdmacm/cma.c:1932
#3 0x0000000000401c8a in run () at
/home/lizhijian/rdma-core/librdmacm/examples/rdma_flush_server.c:132
#4 0x00000000004021ea in main (argc=7, argv=0x7fffffffe228)
at /home/lizhijian/rdma-core/librdmacm/examples/rdma_flush_server.c:282
> Jason
>
next prev parent reply other threads:[~2022-11-28 10:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 8:19 [for-next PATCH v6 00/10] RDMA/rxe: Add RDMA FLUSH operation Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 01/10] RDMA: Extend RDMA user ABI to support flush Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 02/10] RDMA: Extend RDMA kernel verbs " Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 03/10] RDMA/rxe: Extend rxe user " Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 04/10] RDMA/rxe: Allow registering persistent flag for pmem MR only Li Zhijian
2022-11-22 14:46 ` Jason Gunthorpe
2022-11-23 6:12 ` lizhijian
2022-11-16 8:19 ` [for-next PATCH v6 05/10] RDMA/rxe: Extend rxe packet format to support flush Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 06/10] RDMA/rxe: Implement RC RDMA FLUSH service in requester side Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 07/10] RDMA/rxe: Implement flush execution in responder side Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 08/10] RDMA/rxe: Implement flush completion Li Zhijian
2022-11-16 8:19 ` [for-next PATCH v6 09/10] RDMA/cm: Make QP FLUSHABLE Li Zhijian
2022-11-22 14:52 ` Jason Gunthorpe
2022-11-23 6:07 ` lizhijian
2022-11-24 17:39 ` Jason Gunthorpe
2022-11-25 2:22 ` lizhijian
2022-11-25 14:16 ` Jason Gunthorpe
2022-11-28 10:23 ` lizhijian [this message]
2022-12-05 10:07 ` lizhijian
2022-12-05 17:12 ` Jason Gunthorpe
2022-12-07 1:25 ` lizhijian
2022-11-16 8:19 ` [for-next PATCH v6 10/10] RDMA/rxe: Enable RDMA FLUSH capability for rxe device Li Zhijian
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=3c84d3ca-88f9-0995-4c0a-2b5dc69670b6@fujitsu.com \
--to=lizhijian@fujitsu.com \
--cc=dan.j.williams@intel.com \
--cc=jgg@nvidia.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox