From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4305767153456378078==" MIME-Version: 1.0 From: Valeriy Glushkov Subject: Re: [SPDK] A problem with SPDK 19.01 NVMeoF/RDMA target Date: Wed, 06 Feb 2019 07:59:29 +0000 Message-ID: In-Reply-To: 48D118FF-A7D9-4EDD-B2A6-2A78D1A5B1E7@intel.com List-ID: To: spdk@lists.01.org --===============4305767153456378078== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Jim, Our module is an implementation of the NVMeoF/RDMA host. It works with SPDK 18.10.1 well, so the problem seems to be related to the = SPDK 19.01 code. I can see that the RDMA request's state engine have been changed in the = recent SPDK release. So it would be great if the author of the modifications could take a look = at the issue... Thank you for your help! -- = Best regards, Valeriy Glushkov www.starwind.com valeriy.glushkov(a)starwind.com Harris, James R =D0=BF=D0=B8=D1=81=D0=B0=D0=BB= (=D0=B0) =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0= =BC=D0=B5 Wed, 06 = Feb 2019 02:35:38 +0200: > Hi Valeriy, > > Can you provide more details on this test host module? > > Thanks, > > Jim > >> On Feb 5, 2019, at 4:41 AM, Valeriy Glushkov = >> wrote: >> >> Hi All! >> >> It seems there is an issue in the 19.01 code that leads to a request = >> stays unanswered and our test NVMeoF/RDMA host module does not receive = >> the completion. >> >> From the debug log of the target: >> =3D=3D=3D=3D=3D=3D=3D >> rdma.c:1508:spdk_nvmf_rdma_request_process: *DEBUG*: Request 0x1402a20 = >> entering state 1 >> rdma.c:1508:spdk_nvmf_rdma_request_process: *DEBUG*: Request 0x1402a20 = >> entering state 2 >> rdma.c:1414:spdk_nvmf_rdma_request_parse_sgl: *DEBUG*: Request = >> 0x1402a20 took 1 buffer/s from central pool >> rdma.c:1508:spdk_nvmf_rdma_request_process: *DEBUG*: Request 0x1402a20 = >> entering state 5 >> request.c: 121:nvmf_trace_command: *DEBUG*: Admin cmd: opc 0x02 fuse 0 = >> cid 2751 nsid 4294967295 cdw10 0x001e0002 >> request.c: 127:nvmf_trace_command: *DEBUG*: psdt 0 >> request.c: 136:nvmf_trace_command: *DEBUG*: SGL: Keyed (Inv): addr = >> 0xffffb28f67223dd0 key 0x8294c len 0x200 >> ctrlr.c:1285:spdk_nvmf_ctrlr_get_log_page: *DEBUG*: Get log page: = >> LID=3D0x02 offset=3D0x0 len=3D0x7c >> request.c: 92:spdk_nvmf_request_complete: *DEBUG*: cpl: cid=3D2751 = >> cdw0=3D0x00000000 rsvd1=3D0 status=3D0x0000 >> rdma.c:1508:spdk_nvmf_rdma_request_process: *DEBUG*: Request 0x1402a20 = >> entering state 7 >> rdma.c:1508:spdk_nvmf_rdma_request_process: *DEBUG*: Request 0x1402a20 = >> entering state 8 >> rdma.c:1508:spdk_nvmf_rdma_request_process: *DEBUG*: Request 0x1402a20 = >> entering state 8 >> =3D=3D=3D=3D=3D=3D=3D=3D >> >> The same host module works well with the SPDK 18.10.1 NVMf target. >> >> Is this a bug in the recent SPDK code? >> >> -- >> Best regards, >> Valeriy Glushkov >> www.starwind.com >> valeriy.glushkov(a)starwind.com >> = --===============4305767153456378078==--