[libfabric-users] multi-receive CQ entry with FI_MULTI_RECV, not the last one read by fi_cq_read()?
gregory.titus at hpe.com
Wed Jun 24 16:02:26 PDT 2020
No, there is only the one buffer, which is posted at the beginning of time and then re-posted whenever I read a FI_MULTI_RECV CQ event. And while buf.buf through buf.buf are earlier in the buffer than buf.buf, they are not anywhere near the beginning of it.
From: Hefty, Sean <sean.hefty at intel.com>
Sent: Wednesday, June 24, 2020 4:50 PM
To: Titus, Greg <gregory.titus at hpe.com>
Cc: libfabric-users at lists.openfabrics.org <libfabric-users at lists.openfabrics.org>
Subject: RE: multi-receive CQ entry with FI_MULTI_RECV, not the last one read by fi_cq_read()?
> I called fi_cq_read(cq, buf, 5) and it filled in buf with 5 entries.
> buf.flags==FI_MSG|FI_RECV and buf.buf was near the end of the multi-receive
> buffer. buf.flags==FI_MULTI_RECV. buf.flags==FI_MSG|FI_RECV and buf.buf was
> much earlier in the multi-receive buffer than buf.buf. buf and buf were the
> same as buf but with different .buf pointers though both were also much earlier in
> the multi-receive buffer than buf.buf.
Are you sure that the buffer was only posted once? When is the buffer reposted?
The scenario you're describing is possible if the buffer is posted twice, or if a single buffer were split and posted as two receives. For example:
If buf.buf + buf.len is near the end of the buffer...
buf would mark the buffer as done (FI_MULTI_RECV set)
buf.buf would then reference the start of the buffer again
buf.buf would be near buf.buf + buf.len
buf.buf ~ buf.buf + buf.len
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libfabric-users