[ofa-general] uDAPL EVD queue length issue

Steve Wise swise at opengridcomputing.com
Thu Dec 6 04:52:08 PST 2007


Arlin Davis wrote:
>>>
>>> I'm running OFED 1.2.5 and using Chelsio.
>>>
>>  From the linux rdma verbs perspective, ibv_create_cq() will create a 
>> cq that is >= the requested depth.  The fact that mthca always bumps 
>> the size up to the next power of 2 isn't something udapl can rely on.
> 
> It doesn't.
> 
> uDAPL passes the users requested qlen directly to the verbs 
> ibv_create_cq call (dapl_openib_cq.c) and then uses the returned qlen to 
> allocate EVD's (dapl_evd_util.c) and a ring buffer 
> (dapl_ring_buffer_util.c) for managing the free and pending events.
> 
> The EVD's are allocated based on returned qlen from verbs and the 
> ring_buffer is allocated based on qlen, next power of 2 minus 1. Unless 
> I am missing something, I don't see how we can get less then what is 
> requested.
> 
>>
>> Here's the crux:  If creating a udapl evd of 256 results in a cq of 
>> 256 and the udapl returns a evd with size 255, then udapl is broken...
> 
> Yes, I agree. But I don't see how this is happening.
> 
> Here is output from my dtest when requesting 256 and verbs returning the 
> same qlen. You can see before and after verbs we get 256, the rbufs are 
> 511, and the query EVD call returns 256 to the user.
> 
>  cq_object_create: (0x519bb0,0x519d00)
> dapls_ib_cq_alloc: evd 0x519bb0 cqlen=256
> dapls_ib_cq_alloc: new_cq 0x519d60 cqlen=256
>  setup_async_cb: ia 0x518270 type 2 hdl 0x519bb0 cb 0x2a957c8e70 ctx 
> 0x519bb0
>  >>> rbuf_alloc: size 256 rsize 511
>  >>> rbuf_alloc: size 256 rsize 511
> dapl_evd_create () returns 0x0
> 
> 9920 dto_req_evd QLEN - requested 256 and actual 256
> 9920 Create events done
> 
> Can you turn up DAPL debug(DAPL_DBG_TYPE=0xffff) so I can see what is 
> happening?
> 
> Thanks,
> 
> -arlin
> 
> 
> 
> 

Sorry for the noise guys.  Looks like this is a cxgb3 bug.


Steve.



More information about the general mailing list