[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