[openib-general] Re: [PATCH 0/2] opensm: low-level QoS implementation

[Sasha Khapyorsky]

On 18:04 Tue 09 May     , Eitan Zahavi wrote:
> 
> > > [EZ] Please note that algorithm to validate the applicability of the
> > > above on the
> > >          particular fabric is still required as not all devices
> support
> > > the 16 VLs
> > 
> > VL numbers are translated according to port's capabilities and
> > configured OperVLs (the numbers are MODed).
> [EZ] I am not following what you mean here. Can you elaborate?

For example for ports with VLCap and OperVLs VL0-7 such SL2VL table
template

  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7

will be translated to such

  0,1,2,3,4,5,6,7,0,1,2,3,4,5,6,7

SL2VL table.

> > > and not all
> > >          devices must support VLArb of 8 entries. In such cases we
> > > should at least provide
> > >           an error describing why the provided setting is
> un-realizable.
> > 
> > In the case of "short" VLArb table the template will be truncated
> > (silently) to meet port's capabilities. This is not a error, right?
> [EZ] If you do not have an entry for a VL in the VLArb (both high and
> low) tables it means this VL will never be scheduled for transmission.
> So anybody using this VL will be "blocked".

But size of low table cannot be less than number of data VLs supported
by the port. So the case you described is possible only when it is
specially configured (like this:
qos_vlarb_low=1:1,1:1,1:1,1:1,1:1...), and then I guess that it is what
was desired by admin.

> An algorithm to do SL2VL in
> such cases can be used to avoid these problems.

> > 
> > > [EZ] I do not see how the above could be used. Instead I do see
> groups
> > > of nodes as being
> > >          assigned different QoS levels. As we defined "groups of
> nodes"
> > > in the partition
> > >          policy I would propose using the partitions as the means to
> > > define node groups.
> > > [EZ] So I propose to keep the "trivial" implementation without this
> > > level of control.
> > 
> > At least it does not hurt, and somebody tell me that this will be
> > useful. So I would prefer to start with this feature.
> 
> [EZ] OK. But in the future the policy will override these default
> parameters.

Yes, it may override it in the future. We will clean it up as obsolete
code then.

Sasha.