On Fri, 3 Jun 2005, Itamar Rabenstein wrote:
*/
Could we initialize the ia_attr.max_evd_qlen value correctly in the
provider?
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?
Again, why not initialize these correclty in the provider?
again the same as max_evd_qlen value
Good catch. 255 was not a good value to have been using.
Could we use pt_ptr->provider_attr.optimal_buffer_alignment instead?
if it is 256 that it is O.k but i dont think we should fix it the current
code is O.k for me.
Index: test/dapl_bpool.c
===================================================================
--- test/dapl_bpool.c (revision 2522)
+++ test/dapl_bpool.c (working copy)
@@ -388,7 +388,7 @@
u64
DT_Bpool_GetRegBuff (Bpool * bpool_ptr, int index)
{
- return ( bpool_ptr->reg_addr + index * bpool_ptr->seg_size );
+ return (virt_to_phys(DT_Bpool_GetBuffer(bpool_ptr,index)));
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?
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?
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
