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:[EMAIL PROTECTED] > Sent: Tuesday, May 09, 2006 7:06 PM > To: Eitan Zahavi > Cc: Hal Rosenstock; [email protected]; 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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
