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 <[EMAIL PROTECTED]> wrote: > > >> -----Original Message----- >> From: Roland Dreier [mailto:[EMAIL PROTECTED] >> >> 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 > [email protected] > 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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
