somenath wrote: >> I think this evaluates ib_poll_cq(..) < 0 before doing the >> assignment. Since the expression evaluates to false, count is >> assigned 0. Can you try modifying this to: >> >> if ((count = ib_poll_cq(..)) < 0) >> >> - Sean > > > I added that stuff, but it didn't make a difference...it still returned > 0....
If ib_poll_cq() is truly returning 0, but with a valid wc, then this is a bug. (I'm pretty sure that the additional parens are needed in any case, and you'll also want to swap your ib_poll_cq and ib_req_notify calls back around.) I have never seen this issue, and I'm sure that we would have heard about it if others had. Nothing obvious jumped out at me when looking at the mthca completion code. Maybe you've tried this, but can you break the count = ib_poll_cq() out from the if statement, print count and the wc structure immediately before and after the call, and post the results? > looks like, I may be getting a valid entry even if ib_poll_cq() is > returning zero... > is that possible? You should not be getting a valid wc if the call returns 0. For most applications this would result in a lost completion. > dump of wc entry from recv side, looks like many are valid entries (like > wr_id, length, op etc..) This could just be left over data from the stack, but... > wr_id=0x10118163c00 status=0x0 op=0x80 Does the wr_id match the value that you set on the work request? (I'm assuming that it does based on your previous comment.) The opcode does match IB_WC_RECV. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
