On Wed, Jul 31, 2019 at 11:51:58AM +0300, Gal Pressman wrote:
> On 31/07/2019 11:34, Leon Romanovsky wrote:
> > 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.
>
> Does OK mean you're OK with counting DC QPs after this patch?
I'm OK with the idea, I'm not OK with the description.
Thanks
