> > For example, can sends be re-ordered by
> > the network, such that they may be received in the opposite order
> that they
> > were sent?
>
> No. Only rdma reads and writes. Table 79 of IB spec still holds true.
> In internal patch review I had the table, but since there was no
> change, I just removed it.
> I think it's worth to mention in the out_of_order.txt that it still
> holds true. I will add this line.
>
> I would also document which compliant statements are not applicable
> when such flag is set.
> How about having responder side table, similar to table 79 in
> Documentation/out_of_order.txt
> That makes it more readable for users.
>
> > Can rdma writes be processed out of order, such that the target
> > data ends up with some sort of interleaving of the written data?
> Yes.
>
> > Are there size limits to ordering constraints?
> No.
My questions were more examples of the level of detail that I think any API change needs to (eventually) be able to address. Libibverbs is supposed to work over iwarp as well, which has different ordering semantics already. I think that was part of Steve's point as to why any change is needed to the api.
IMO, read and write ordering should be determined separately from the perspective of the api. This is exposing a hw specific limitation where these semantics are joined, and send/receive is not supported.
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
