[openib-general] [PATCH] IB/ipoib: NAPI
Roland Dreier
rdreier at cisco.com
Mon Sep 25 07:29:53 PDT 2006
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.
More information about the general
mailing list