>> I think it's possible for the function to return without having filled in a >wc. >> > >So its busted? Or is this intended behavior?
Depends on the point of view, I guess. :) It would be nice to avoid that situation. >Is rdma_get_send_completion() supposed to return exactly one wc? If so >then the 2 polls can cause a wc to get silently discarded. I must >still not be understanding the intended use? How can a wc get discarded? Maybe the return code from ibv_poll_cq is confusing you? If the first poll finds a wc, ibv_poll_cq returns 1, and we exit the function. Otherwise, we rearm the cq, then poll again to make sure that nothing got missed. >I would think this should just be: > >get_cq_event() >notify_cq() >poll() This requires arming the CQ up front. I was also trying to avoid the overhead of always calling get_cq_event and notify_cq to just pull a completed request off of the work queue. >> The only drawback I see is that it's theoretically possible to build up a >queue >> of cq events in the kernel. Not sure how to fix that. Any ideas? >> >That can always happen, yes? It seems like it should be avoidable. Maybe 1 event can queue up, but I think we can prevent more by not rearming until that event gets pulled. If nothing else, I think this discussion shows why we need this sort of wrapper. :) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
