Here is an alternative solution. If instead of setting a hard coded
value for the priority of CM, we make it use the priority of the MTL
that get selected, we can solve this problem on a case by case
approach by carefully setting the MTL's priority (bump up the portals
and PSM one and decrease the MX MTL). As a result we can remove all
the extra selection logic and priority management from the
pml_cm_component.c, and still have a satisfactory solution for
everybody.
george.
On Aug 11, 2009, at 15:23 , Brian W. Barrett wrote:
On Tue, 11 Aug 2009, Rainer Keller wrote:
When compiling on systems with MX or Portals, we offer MTLs and BTLs.
If MTLs are used, the PML/CM is loaded as well as the PML/OB1.
Question 1: Is favoring OB1 over CM required for any MTL (MX,
Portals, PSM)?
George has in the past had srtong feelings on this issue, believing
that for MX, OB1 is prefered over CM. For Portals, it's probably in
the noise, but the BTL had been better tested than the MTL, so it
was left as the default. Obviously, PSM is a much better choice on
InfiniPath than straight OFED, hence the odd priority bump.
At this point, I would have no objection to making CM's priority
higher for Portals.
Question 2: If it is, I would like to reflect this in the default
priorities,
aka have CM have a priority lower than OB1 and in the case of PSM
raising it.
I don't have strong feelings on this one.
Brian
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
