Hi Jason, > -----Original Message----- > From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, June 12, 2017 11:29 AM > To: Parav Pandit <parav@xxxxxxxxxxxx> > 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 Mon, Jun 12, 2017 at 04:19:37PM +0000, Parav Pandit wrote: > > > So, - to your question - shouldn't that be a flag to disable > > out-of-order writes? By default, its disabled at RDMA level. > > Bart's point is that it is not disabled, by default, it is platform specific by > default. > > Your patch makes makes it more likely a ULP will see out of order writes, > but it is already the case that any ULP that relies on this is platform specific > and/or broken. > > I think the answer to Bart's question is that some MPI ULPs are 'broken' > and only work on x86 - setting this bit by default would cause them to stop > working. It is unfortunate this is the rare case. There are two bits as described in usage section of Documentation. (a) device capability bit, which indicates that device is capable of processing out-of-order packets. This doesn't mean it is enabled. (b) per QP enable bit where application can enable it if it wants to. So no bit is set by default. So application which sets this per QP bit, and still have some logic for polling on write data, would be wrong/bug for that application. > > I would suggest at least using the inverted sense like Bart describes in the > kernel - every kernel ULP is safe. > I don't see a need to use inverted sense in code. I can surely make documentation more descriptive as Bart suggested. > Jason -- 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
