> -----Original Message----- > From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma- > owner@xxxxxxxxxxxxxxx] On Behalf Of Leon Romanovsky > Sent: Monday, June 12, 2017 1:49 AM > To: Doug Ledford > Cc: linux-rdma@xxxxxxxxxxxxxxx; Idan Burstein > Subject: [PATCH rdma-next 0/3] Support out of order data placement > > Hi Doug, > > This patch set which is based on v4.12-rc4 comes from Parav and it > adds support for out of order data placement for RDMA read and > write requests. > > Thanks > > --- > >From Parav: > > In certain fabric configurations IB packets for a given QP may take up > different paths in a network from source to destination. This results > into reaching packets out of order at the receiver side. Instead of > dropping packets, handling out of order packets can improve overall > network performance in following ways: > * improve network utilization by avoiding retransmission > * avoiding latency increase due to retransmission > > This patchset allows HCA to expose out of order data placement > capability to users who can take benefit of such feature. > > This is optional feature of an HCA and enablement of this feature > is done on per QP basis. The optional QP attribute is set when a QP > state is changed from INIT to RTR. > > Out of order data placement capability indicates that if HCA receives > out of order RDMA packets, their data placement can be done at the > desired memory destination given in the packet(s). This is applicable > to RDMA read and write operations. > > Send queue work requests are still completed in-order regardless of > their data placement order at requester or responder side. > > In-order semantics is always guaranteed by setting the Fence > indicator for appropriate WRs. > > An application shall not depend on the contents of the RDMA write buffer > at the responder until one of the following occurred: > - Completion of the RDMA WRITE with immediate data receive completion. > - Arrival and completion of the subsequent SEND message. > - Update of a memory element by subsequent ATOMIC operation. > > An application shall not depend on the contents of the RDMA read buffer > at the requester until one of the following occurred: > - Completion of the RDMA READ work request if requested or such > work request completes with error status. > - Completion of the subsequent work request. Given the application follows the above semantics, why does it care if data is placed out of order? IE Why does this impact the application API at all? Steve. -- 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
