FI_TAGGED and ordering

[rajachan]

fi_tagged(3) mentions:

In general, message tags are checked against receive buffers in the order in which messages have been posted to the endpoint. See the ordering discussion below for more details.

Is the interface also assuming FI_ORDER_SAS for the tag-match or is it only guaranteeing that incoming/unexpected messages (which could be unordered) will match against receives in posted order? For MPI (well, at least pre-4.0 standard which does not allow message overtaking with a comm info hint), FI_TAGGED does not make sense without FI_ORDER_SAS, but I wonder if the libfabric interface is offering the same guarantee. If so, the manpage could use clarification.

[rajachan]

In other words, a provider without FI_ORDER_SAS caps could process two messages carrying the same tag from the same source and introduce non-determinism in matching, even if the tags are checked against receive buffers in the posted order.

...which is fine and could be what an app desires. In fact, I'd argue it is good to keep the two separate and leave it up to the apps to decide what level of ordering should be enforced. Just wanted to clarify current intent as described in the manpage.

[shefty]

The comment is saying that the receives will be checked in the order that they were posted. This is also true for non-tagged receives. For example, no attempt is made to match based on best fit. However, if a src_addr is associated with the receive, then matching may not behave as a true FIFO. That's why there's the wishy-washy wording "in general".

This is independent from message ordering (SAS). If SAS is not set, then match ordering may not be deterministic.