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

[Eitan Zahavi]

Hi Sasha

Thanks for clearing the issues.
I'm OK with the RFC.

Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL


> -----Original Message-----
> From: Sasha Khapyorsky [mailto:sashak at voltaire.com]
> Sent: Tuesday, May 09, 2006 7:06 PM
> To: Eitan Zahavi
> Cc: Hal Rosenstock; openib-general at openib.org; Yael Kalka; Ofer Gigi;
Eli Dorfman
> Subject: Re: [PATCH 0/2] opensm: low-level QoS implementation
> 
> 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.