This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Brian W. Barrett wrote:
> How about removing the MCA parameter from my earlier proposal and just
> having r2 filter out the sendi calls if there are multiple BTLs with
> heterogeneous BTLs (ie, some with sendi and some without) to the same
> peer. That way, the early sendi will be bypassed in that case. But
> for the cases of BTLs that support sendi in common usage scenarios
> (homogeneous nics), we'll get the optimization? Does that offend you
> George? :)
I think I'm just going to punt. The PML strikes me as very complicated
and in a certain sense brittle. You talked in San Jose about putting
the PML on a diet. Great. Go for it. For a newbie like me, it's a
Here's another example. Even if you only go for the cases where
everyone has (or does not have) a sendi function, they may have
different eager limits. (Though, somehow there is a well-defined list
of "eager" BTLs that does not depend on message length. Ain't life
interesting!) So, you run into the same problem of not preserving
today's BTL-looping order. If you want to preserve the current behavior
-- looping over BTLs and trying all your tricks for each one
(sendi/send, eager/long, etc.) before moving on to the next BTL --
you're back to diving deep into the PML code, at which point the send
request has been initialized and you've eaten up a lot of instructions.
I don't think I have sufficient expertise, mandate, or remaining energy
to be effective here.