On Wed, Jul 31, 2019 at 10:53:10AM +0300, Gal Pressman wrote:
> On 31/07/2019 10:46, Leon Romanovsky wrote:
> > On Wed, Jul 31, 2019 at 10:05:31AM +0300, Gal Pressman wrote:
> >> On 30/07/2019 18:19, Leon Romanovsky wrote:
> >>> On Tue, Jul 30, 2019 at 04:49:52PM +0300, Gal Pressman wrote:
> >>>> On 30/07/2019 16:38, Leon Romanovsky wrote:
> >>>>> On Tue, Jul 30, 2019 at 02:01:37PM +0300, Gal Pressman wrote:
> >>>>>> The check for QP type different than XRC has wrongly excluded driver QP
> >>>>>> types from the resource tracker.
> >>>>>>
> >>>>>> Fixes: 78a0cd648a80 ("RDMA/core: Add resource tracking for create and destroy QPs")
> >>>>>
> >>>>> It is a little bit over to say "wrongly". At that time, we did it on purpose
> >>>>> because it was unclear how to represent such QP types to users and we didn't
> >>>>> have vendor specific hooks introduced by Steve later on.
> >>>>
> >>>> It's very confusing to see a test running and zero QPs in "rdma res".
> >>>> I'm fine with removing the "wrongly" :), but I still think this should be
> >>>> targeted to for-rc as a bug fix.
> >>>
> >>> Yes, please remove "wrongly" and change Fixes line to be
> >>> "Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation")",
> >>> because before addition of EFA driver all other drivers had QPs.
> >>
> >> How are DC QPs being counted?
> >
> > They were not counted on purpose. We didn't imagine acceptance of
> > non-RDMA driver which doesn't support any standard QPs and doesn't
> > work with kernel verbs.
>
> Running dcping/perftest over DC shows zero QPs?
No, try it and you will see other QPs.
> On purpose?
> Sounds like a bug to me..
OK.
Thanks
