[openib-general] RE: [patch][kdapl] enable kdapltest -T P

James Lentini jlentini at netapp.com
Thu Jun 9 07:26:46 PDT 2005



On Wed, 8 Jun 2005, Itamar Rabenstein wrote:

>>> Current openib gen2 code is not reporting the max cq size
>> and i dont think
>>> that we should put
>>> a fix number .
>>> if we want to get the number we need Roland to fill this
>> number in mthca but
>>> as Roland said before
>>> "what real App will meed this number?"
>>
>> I see the initialization code you are refering to in
>> mthca_query_device of mthca_provider.c.
>>
>> I think a "real app" would use this number in exactly the same way
>> that dapltest's performance subtest uses it:
>>
>>   pipeline_length = min(max_cqe, max_qp_wr)
>>
>> Why would a limit like the one above be unnecessary?
>
> you can try to printk the value and you will see it is not initialized.
> it is not enough to assign value to the output attr struct
> if this value is not initialized (;-)

Understood.

> i dont mind if Roland will implement it but for now it is not implemented.

I will ping Roland on this subject.

> Please ci the patch for now in order to enable kdapltest -T P
> and if Roland will implement it then unremark the lines.
>
>
>>>>
>>>> Was this also a problem in the transaction test?
>>>>
>>>
>>> Yes but in order to fall on the bug you need to alloc a
>> very small buffer
>>> (like 12 byte)
>>> and this is only in -T P .
>>
>> So is it only in the performance test or would it occur in the
>> transaction test if I specified a small buffer?
>
> It will fail for every small buffer (include in -T T )
>
>>
>> Why do we need to translate the virtual address to a physical address
>> in all cases? Will this interact properly with the transaction test's
>> -M (memory type) option?
>
> Current openib gen2 register only physical memory.
> the code will work also for any -M option .

So I don't make this mistake in the future, can you explain what the 
underlying problem was?



More information about the general mailing list