[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