Re: NFS RDMA test failure as of 5.14-rc1

[Leon Romanovsky <leonro@nvidia.com>]

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@cornelisnetworks.com> 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