[ofa-general] post_recv question

Caitlin Bestler Caitlin.Bestler at neterion.com
Fri Feb 22 09:33:08 PST 2008


Tom Tucker wrote:

> 
> Ok. So what does the HW do with the packet while it's pondering it's
> options? It has to put it somewhere. 

At the point where the RQ/SRQ would be checked the HW should not have
to "put" the packet anywhere. At least not until it can allocate a WQE
or declare a no-buffer-available error.

RDMA is incompatible with cut-through placement directly into a user
buffer.
The hardware has to capture the entire packet before it can legitimately

allocate the correct receive WQE. So it is distinctly feasible for a HW
implementation to simply leave the packet where it is while it completes
a more extended check to ensure that there really is no available recv
WQE.

Or an implementation could adopt the strategy of ensuring that all
RQ/SRQ
WQEs must be very easy for the Hardware to find, and the posting routine
must do whatever is necessary to ensure that this has been done.

Which of many solutions is deployed is up to the implementation. The
semantics
are that after the recv wqe is posted that it *is* in the RQ/SRQ.
Wherever
the RQ/SRQ is represented in host and/or adapter memory, a QP is
responsible
for guaranteeing that it has searched the entire "there" before it
declares
that the recv wqe is "not there".

That involves work on the part of posting recv wqes and/or on allocating
them. But it is up to those entities to divide the work.  They cannot
decide
that the application should solve the problem for them.





More information about the general mailing list