On 6/12/2017 6:54 PM, Parav Pandit wrote:
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().
I have two thoughts here.
1) You seem to assume all consumers are Linux, and do not
need to negotiate. This is a dangerous assumption.
2) I assume that there is some performance benefit to toggling
this setting to non-strict. So, how do existing consumers get
this advantage, especially since they don't need strict
semantics? Bearing in mind that they do have to negotiate
this end-to-end, meaning they require a protocol extension.
Actually. I have a third thought. Since this is an attribute
to qp creation, performed even before establishing a connection,
how does the upper layer know when to set it?
Tom.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
