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?
