All of lore.kernel.org
 help / color / mirror / Atom feed
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, 5 Dec 2022 10:07:11 +0000	[thread overview]
Message-ID: <3d2b0f6d-6214-8d04-8356-852c34563501@fujitsu.com> (raw)
In-Reply-To: <3c84d3ca-88f9-0995-4c0a-2b5dc69670b6@fujitsu.com>

Jason

Could you take a look at this update:
- Make QP FLUSHABLE for supported device only
- add more explanation

commit 1a95f94125b59183d5fc643a917e0a2e7bb07981
Author: Li Zhijian <lizhijian@fujitsu.com>
Date:   Mon Sep 26 17:53:06 2022 +0800

     RDMA/cm: Make QP FLUSHABLE for supported device
     
     Similar to RDMA and Atomic qp attributes enabled by default in CM, enable
     FLUSH attribute for supported device. That makes applications that are
     built with rdma_create_ep, rdma_accept APIs have FLUSH qp attribute
     natively so that user is able to request FLUSH operation simpler.
     
     Note that, a FLUSH operation requires FLUSH are supported by both
     device(HCA) and memory region(MR) and QP at the same time, so it's safe
     to enable FLUSH qp attribute by default here.
     
     FLUSH attribute can be disable by modify_qp() interface.
     
     Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
     ---
     V6: enable flush for supported device only #Jason
     V5: new patch, inspired by Bob
     Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>

diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 1f9938a2c475..603c0aecc361 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -4094,9 +4094,18 @@ static int cm_init_qp_init_attr(struct cm_id_private *cm_id_priv,
                 *qp_attr_mask = IB_QP_STATE | IB_QP_ACCESS_FLAGS |
                                 IB_QP_PKEY_INDEX | IB_QP_PORT;
                 qp_attr->qp_access_flags = IB_ACCESS_REMOTE_WRITE;
-               if (cm_id_priv->responder_resources)
+               if (cm_id_priv->responder_resources) {
+                       struct ib_device *ib_dev = cm_id_priv->id.device;
+                       u64 support_flush = ib_dev->attrs.device_cap_flags &
+                         (IB_DEVICE_FLUSH_GLOBAL | IB_DEVICE_FLUSH_PERSISTENT);
+                       u32 flushable = support_flush ?
+                                       (IB_ACCESS_FLUSH_GLOBAL |
+                                        IB_ACCESS_FLUSH_PERSISTENT) : 0;
+
                         qp_attr->qp_access_flags |= IB_ACCESS_REMOTE_READ |
-                                                   IB_ACCESS_REMOTE_ATOMIC;
+                                                   IB_ACCESS_REMOTE_ATOMIC |
+                                                   flushable;
+               }
                 qp_attr->pkey_index = cm_id_priv->av.pkey_index;
                 if (cm_id_priv->av.port)
                         qp_attr->port_num = cm_id_priv->av.port->port_num;

Thanks
Zhijian


On 28/11/2022 18:23, lizhijian@fujitsu.com wrote:
> 
> 
> 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

  reply	other threads:[~2022-12-05 10:08 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
2022-12-05 10:07               ` lizhijian [this message]
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=3d2b0f6d-6214-8d04-8356-852c34563501@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 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.