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
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
>> 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.
> devel mailing list