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 labyrinth.
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.
