[ofa-general] [PATCH 1 of 3] IB/verbs: add cq comp_vector support in core

[Hoang-Nam Nguyen]

> > 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