On Tue, Jul 27, 2021 at 02:38:57PM -0300, Jason Gunthorpe 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. > > 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? When I reviewed Haakon's patch, I saw that all accept/listen/e.t.c. events modify QP from RESET to INIT. This is how we lost extra transition. Thanks > > Jason
