[ofa-general] Managing work completions (libibverbs)

[Roland Dreier]

Yes, exactly: by keeping your own count, you avoid the pthread lock
overhead in ack_events.

The acking of events is required to avoid a race where a consumer gets
an event for a CQ after destroying that CQ.

 - R.

On 11/5/08, Kelly Burkhart <kelly at tradebotsystems.com> wrote:
>
>
>> -----Original Message-----
>> From: Roland Dreier [mailto:rdreier at cisco.com]
>>
>> You can use epoll to get comp channel events, but you'll need
>> to collect
>> the event with ibv_get_cq_event() to rearm things.  epoll
>> tells you when
>> the fd becomes readable, but you'll need to actually read all the
>> events queued on the fd before waiting again.  The overhead of
>> ibv_get_cq_event() should not be too high compared to the overhead of
>> sleeping and getting woken up again by an interrupt, and you
>> can always
>> amortize ibv_ack_cq_events() by just keeping a counter of the
>> number of
>> events you read and only calling ibv_ack_cq_events() occasionally.
>
>
> Digging through the code to see what resource I hog if I don't ack
> frequently enough:  It appears that ibv_ack_cq_events only increments
> an integer in the CQ (and doesn't free or return some resource).  So I
> could just count gets and ack them all immediately prior to
> destructing the CQ.
>
> Why be so picky about matching acks with gets?
>
> -K
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>

-- 
Sent from my mobile device