> On Jul 27, 2021, at 1:38 PM, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > On Tue, Jul 27, 2021 at 05:35:46PM +0000, Marciniszyn, Mike wrote: >>>> On Jul 27, 2021, at 1:14 PM, Marciniszyn, Mike >>> <mike.marciniszyn@xxxxxxxxxxxxxxxxxxxx> wrote: >>>> >>>>> I suspect the patch needs to be reverted or NFS RDMA needs to handle >>>>> the transition to INIT? >>> >>> If I'm reading nvmet_rdma_create_queue_ib() correctly, it invokes >>> rdma_create_qp() then posts Receives. No >>> ib_modify_qp() there. >>> >>> So some ULPs assume that rdma_create_qp() returns a new QP in the >>> IB_QPS_INIT state. >>> >>> I can't say whether that is spec compliant or even internally documented. >>> >> >> This from the spec: >> >> C10-20: A newly created QP/EE shall be placed in the Reset state. > > rdma_create_qp() is a CM function, it is not covered by the spec. > > The question is if there is any reasonable basis for ULPs to require > that the QP be in the INIT state after the CM creates it, or if the > ULPs should wait to post their recvs until later on in the process. Existing ULPs that have posted Receives well before the CM_ESTABLISHED event suggest that there is a longstanding expectation that a QP returned from rdma_create_qp() is in a state that is ready for posted work. > Haakon's original analysis said that this was an INIT->INIT > transition, so I'm a bit confused why we lost a RESET->INIT transition > in the end? Perhaps the patch should have removed the ib_modify_qp() from cma_modify_qp_rtr() instead. -- Chuck Lever
