[ofiwg] respecting message boundaries in recv
Paolo Inaudi
p91paul at gmail.com
Thu Aug 6 03:16:22 PDT 2015
Hi everybody,
I'm implementing a libfabric provider and I'm unsure about the
implications of the statement 'Message boundaries are maintained' in
fi_recv* operations. In particular, what should happen if a receive
buffer posted with fi_recv (the same applies to fi_recvv or fi_recvmsg)
is smaller than the size of the message to be received?
I see some options:
1. Nothing is received, and an error is inserted into the completion
queue (FI_EMSGSIZE seems to be the right error code, with the len field
containing the message length).
2. Posted buffer is filled, and a completion is generated. If completion
format is at least FI_CQ_FORMAT_MSG, the len field of the completion is
set to the size of the message to be received (which means bigger than
the buffer size; this way the application is informed that the message
is bigger than expected)
3. Posted buffer is filled, and a completion is generated. If completion
format is at least FI_CQ_FORMAT_MSG, the len field of the completion is
set to the size of the buffer. The application must have its own way to
know that the message is not completely received.
3. Posted buffer is filled, but no completion is generated until a new
buffer is posted which is big enough to contain the remainder of the
message (this seems quite bad, since I don't see a practical way for the
application to know when this happens).
Moreover, given option 2 or 3 is the right one, what should happen when
another receive buffer is posted?
1. It should be filled with the remainder of the partially read message
2. It should be filled with the partially read message as a whole (i.e.
the already read part + the remainder)
3. It should be filled with the next message in the queue (that is, the
remainder gets discarded, and the application must retransmit it)
Really sorry of bothering you if the answer is in the manpages, but I
was unable to spot it. Also, I hope it is fine I posted here despite not
being a libfabric developer myself.
Paolo Inaudi
More information about the ofiwg
mailing list