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. 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? Jason