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? On purpose?
Sounds like a bug to me..
