Re: [PATCH RFC]: napi_struct V4

[Roland Dreier <rdreier@cisco.com>]

 > If you have a means in the device (like tg3, bnx2, e1000, and a score
 > of others do) to force the device to trigger a HW interrupt, that's
 > what you do if you detect that events are pending after re-enabling
 > interrupt in the ->poll() handler.

It is possible to trigger an interrupt for IPoIB I think but it will
lead to a fair bit of code, since one would have to do something like
a dummy send operation to generate an event that leads to the
interrupt.  I think this will be rather complex/ugly to implement
because we have to make sure we have space in the send queue to post
the send operation, etc.

 > Frankly I don't think the lock is a big deal and you need something
 > like it anyways typically.

If I understand this correctly, you're suggesting a spin_lock_irqsave()
around the netif_rx_complete() in the poll routine, and a
corresponding lock in the interrupt handler.  That seems like a pretty
big step backwards for performance to me.  Especially since in my
experience, fast machines handling full-MTU traffic often end up being
basically interrupt driven because they drain the RX ring too quickly
to stay in NAPI polling.  Yes, it's "only one more lock" but look at
the tricky smp_mb() usage that tg3, bnx2, etc have to avoid using a
spinlock...

IPoIB can cope but it really seems like an unfortunate feature of
these changes that we can't do something like what we have today,
which imposes no overhead unless an event actually lands in the race
window.

 - R.