From: Roland Dreier <[EMAIL PROTECTED]> Date: Sat, 28 Jul 2007 08:27:18 -0700
> > Most drivers are in good shape, although some still have very > > questionable netif_rx_complete() handling, in that racy area that > > Rusty and myself were discussing today. > > > > My inclination is to wrap those sequences around with an IRQ > > safe spinlock to fix the race provably, and then if driver > > authors want to optimize that away with techniques like those > > that tg3, bnx2, sky2, skge et al. use, that's fine but can > > be done later. > > Ouch... that extra lock seems pretty expensive. Also I'm having a > hard time understanding how the techniques you're alluding to apply to > devices that may miss events when enabling interrupts; the drivers you > mention all seem to be for devices that didn't have the race and > didn't use netif_rx_reschedule() in the old NAPI world. Can you > provide a little more detail on how the lock could be optimized away? 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. Frankly I don't think the lock is a big deal and you need something like it anyways typically. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html