On 12:35 Mon 27 Aug , Hal Rosenstock wrote: > > > > Thanks. > > > > > >>>> + cl_list_t group_list; /* list of group names (strings) */ > > > >>>> + cl_list_t across_list; /* list of 'across' group names > > > >>>> (strings) */ > > > >>>> + cl_list_t vlarb_high_list; /* list of num pairs > > > >>>> (n:m,...), 32-bit > > > >>>> values */ > > > >>>> + cl_list_t vlarb_low_list; /* list of num pairs > > > >>>> (n:m,...), 32-bit > > > >>>> values */ > > > >>> Why cl_list for VLArb? it should be short fixed length arrays? > > > >> Right. > > > >> Since the actual VLArb setup is not implemented yet, I didn't see > > > >> this obvious thing. > > > > But it should be implemented. Right? > > > > > > Sure, but not for OFED 1.3 - we have a feature freeze in 11 days. > > > > Then we will have two QoS managers in parallel, I don't like this too > > much. > > Isn't this needed ? What about LASH ? How is that supported ?
Do you mean potential conflict between LASH and QoS in terms of SL/VLs? > I > thought there were extra options or the like to enable the higher > level QoS functions (manager) ? There is already '--qos' option, do you think it is not enough? Sasha _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
