Hi Jason, > -----Original Message----- > From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, July 19, 2017 12:12 PM > To: Parav Pandit <parav@xxxxxxxxxxxx> > Cc: Tom Talpey <tom@xxxxxxxxxx>; 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 Wed, Jul 19, 2017 at 05:33:52AM +0000, Parav Pandit wrote: > > > It does guarantee that writes don't bypass writes and reads don't bypass reads > (Table 79), and transport operations are executed in their *message* order (C9- > 28): > > "A responder shall execute SEND requests, RDMA WRITE requests and > > ATOMIC Operation requests in the message order in which they are > > received." > > At a minimum, you need to include a version of table 79 in your documentation > that reflects the modified WR ordering rules for this mode, Sure. In fact I had it in internal version before posting upstream, but dropped for some reason. I will add it in v1. > and I'm not sure we > should continue to call this thing a 'RC QP' 1. None of the Reliability property is affected with this optional attribute. So it is still RC QP. > at all to avoid so much confusion. All this details we discussed our email will be described in documentation v1 to avoid confusion. > I recommend you rework this patch series to introduce a relaxed RC QP type > instead of using a flag.. Additionally, 2. It doesn't make sense to introduce 3 more relaxed QP type (RC, XRC initiator, target) for one common attribute among them. 3. New QP type makes it more difficult or impossible to make rdmacm work in future. Active side creates the QP and shared parameters through REQ-RSP messages. Such existing interface would just become impossible to make use of. This attribute is similar to MTU, IRD/ORD etc. I prefer to keep it as optional QP attribute that brings simplicity and it is extendible compare to new QP type. -- 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
