Brian is referring to the "rdma" onesided component (OMPI osd
framework) that directly invokes the BTL functions (vs. using the PML
send/receive functions). The osd matching is quite different than
His concern is that that model continues to work -- e.g., if the rdma
osd component sends a message through a BTL that the other side not
try to interpret and match it as a pt2pt message. Hence, the BTL
would need to learn some new things; e.g., that it can match some
(pml) messages but not all (rdma/osd), or perhaps it would need to
learn about rdma/osd matching as well, or ...(something else)...
IIRC, rdma/osd is the only other non-PML component that sends directly
through the BTLs today. But that may change; I know that there are
some who are working on various optimizations that may use the BTLs
underneath (I don't want to cite them on a public list; this is
unpublished research work at this point).
On Jan 21, 2009, at 1:22 AM, Eugene Loh wrote:
> Brian Barrett wrote:
>> I unfortunately don't have time to look in depth at the patch. But
>> my concern is that currently (today, not at some made up time in
>> the future, maybe), we use the BTLs for more than just MPI point-
>> to- point. The rdma one-sided component (which was added for 1.3
>> and hopefully will be the default for 1.4) sends messages directly
>> over the btls. It would be interesting to know how that is handled.
> I'm not sure I understand what you're saying.
> Does it help to point out that existing BTL routines don't change?
> The existing sendi is just a function that, if available, can be
> used, where appropriate, to send "immediately". Similarly for the
> proposed recvi. No existing BTL functionality is removed. Just
> new, optional functions added for whoever wants to (and can) use them.
> devel mailing list