RE: [PATCH rdma-next 0/3] Support out of order data placement

Parav Pandit
2017-06-12T22:54:50Z

Hi Tom,

> -----Original Message-----
> From: Tom Talpey [mailto:tom@talpey.com]
> Sent: Monday, June 12, 2017 5:20 PM
> To: Parav Pandit <parav@mellanox.com>; Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com>
> Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>; leon@kernel.org;
> dledford@redhat.com; linux-rdma@vger.kernel.org; Idan Burstein
> <idanb@mellanox.com>
> 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.