Hi Tom, > -----Original Message----- > From: Tom Talpey [mailto:tom@xxxxxxxxxx] > Sent: Monday, June 12, 2017 5:20 PM > To: Parav Pandit <parav@xxxxxxxxxxxx>; Jason Gunthorpe > <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> > Cc: Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx>; leon@xxxxxxxxxx; > dledford@xxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; Idan Burstein > <idanb@xxxxxxxxxxxx> > Subject: Re: [PATCH rdma-next 0/3] Support out of order data placement > > On 6/12/2017 5:32 PM, Parav Pandit wrote: > > Hi Tom, > ... > >> > >> I agree with Jason, the bit should be 1 by default, if defined as you > propose. > >> Out-of-order is the norm, not the exception, for ULPs. > >> Honestly, I think you should perhaps consider making it the default > >> on your devices, and allowing only MLX-aware ULPs to turn it off. > >> > > > > There can be cases in deployment where responder has support for > receiving out-of-order, but requester doesn't. > > Yuck! So this needs to be negotiated end-to-end, and by the upper layer? > Talk about barriers to adoption, and opportunities for disaster. > As Jason confirmed that all Linux kernel consumers are coded to be compliant to o9-20 requirement, So I think kernel based rdma-cm consumers can be transparently enabled end-to-end without ULP's involvement with rdma_accept() and rdma_connect(). That would be separate patchset for it whenever rdmacm is extended for negotiation, after testing them. We haven't planned that yet. > Tom. ��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
