Michael> Actually, the reason it is hard to come up with the name
Michael> is that what this enables is the natural poll/request
Michael> notification order.
Over the weekend and I thought about this and I came up with an idea I
kind of like, inspired by Todd Rimmer's comments about poll-and-notify.
We could change ib_req_notify_cq() to have an extra parameter:
static inline int ib_req_notify_cq(struct ib_cq *cq,
enum ib_cq_notify cq_notify,
int *lost_event_possible)
and if non-NULL is passed in for lost_event_possible, then
req_notify_cq should do the equivalent of a CQ peek after arming the
CQ event.
Of course mthca would just set *lost_event_possible to 0 without
needing to do any check.
(The reason I make it a pointer parameter rather than just using the
return value is so that consumers don't need to take the potential
cost of a CQ peek on devices where arming a CQ is cheap but peeking in
a CQ might require an extra lock or something).
What do you think?
- R.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
