> > Hello Michael and Roland! > > How about a new verb delivering number of cqs associated with a > > comp_vector like this > > > > /** > > * Returns number of cqs assigned to comp_vector > > * @return < 0 in error case eg invalid comp_vector > > */ > > int ib_query_comp_vector(struct ib_device *dev, int comp_vector); > > > > A consumer or ULP would be able to pick an "empty" comp_vector. > > Surely that does not prevent that a certain comp_vector resp. IRQ > > can be "overloaded", and that's another topic. > > Thanks > > Nam > > PS: I'm waiting for your comments first, a patch will come later. > > I'm not convinced it's an interesting metric. > A CQ which has multiple QPs assigned to it might get more traffic > than a CQ which only has a single QP. That's true for association between CQ and QPs. > My gut feeling would be that once ULPs learn to use multiple vectors, > each ULPs will spread across them evenly, without help from provider. Enabling multiple vectors is to be done by a provider. ULP can utilize it by checking num_comp_vector. Above simple metric could be provided in ib_core. Anyway, as Shirley stated in her email, using comp_vector per port will help a lot, at least on ppc64 and with ehca - for other HCAs I haven't benchmarked. And that metric allows ULP to implement such one approach. Nam
_______________________________________________ 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
