[openib-general] [PATCH] IB/ipoib: NAPI
Roland Dreier
rdreier at cisco.com
Mon Sep 25 09:45:58 PDT 2006
Michael> But this has a disadvantage over the device-wide flag:
Michael> when flag is device-wide, we can just have 2 polling
Michael> routines - with and without peek - and select the correct
Michael> one at device open depending on the hardware
Michael> capabilities. Thus we can avoid a conditional branch on
Michael> the fast path, which I think is nice.
Yeah, but I can't make up my mind whether two polling routines is a
good thing or a bad thing. We get a very specific optimization, but
we have two copies of the same code then.
Michael> On a separate note - ib_req_notify_cq is also testing the
Michael> lost_event_possible flag - so now we have 2 conditional
Michael> branches on fast path, and this hurts all ULPs. Ugh.
I suspect that the cost here is minimal -- lost_event_possible is
going to be in a register, etc.
Michael> If we extend the interface, I would rather make a new
Michael> call ib_req_notify_and_peek_cq(truct ib_cq *cq, enum
Michael> ib_cq_notify cq_notify) that returns 0 on empty CQ, 1 on
Michael> non-empty and negative on error.
And again, I don't want to make the interface too fat...
There are a few of tradeoffs here: microoptimization
vs. maintainability, IPoIB & NAPI vs. all other ULPs...
- R.
More information about the general
mailing list