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

Parav Pandit
2017-06-12T17:46:34Z

Hi Jason,

> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]
> Sent: Monday, June 12, 2017 12:32 PM
> To: Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Cc: Bart Van Assche <Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>; leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org;
> dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Idan Burstein
> <idanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Subject: Re: [PATCH rdma-next 0/3] Support out of order data placement
>
> On Mon, Jun 12, 2017 at 05:28:00PM +0000, Parav Pandit wrote:
>
> > > Exactly - all spec conformant ULPs are compatible with enabling this
> > > new function of mlx5.
>
> > This per QP attribute is for read and write both. So responder can receive
> out-of-order read responses.
> > And HCA's QP need to be told to accept it that way, which by default
> doesn't.
>
> I think this one flag is conflating too many things then.
>
Too many flags just confuses end-user for read/write/requester/responder etc.
Also there isn't well established use case either where user wants to do only certain things.

> Obviously sending out of order packets is not spec conformant, and I don't
> think your discussion is clear enough, as this change to send side certainly
> was not clear to me.
>
Ok. I can make Documentation more elaborate that describe summary of this discussion + Bart's point.

> I'm not excited about a new end-to-end flag without some kind of
> negotiation scheme, and I'm not excited about this being in any of the
> common APIs.
Many applications do out-of-band negotiation or static configuration and its unrelated to the patchset.
So lack of negotiation shouldn't be issue. Its outside the scope of this verb extension anyway.

>
> Perhaps it should be in libmlx5 instead.

We think that its best usable through ibv_modify_qp because it's really simple enough and well documented which will address inputs given in this discussion.

>
> Jason