A spinlock is expensive in the fast path, which is why Jeff says it's invasive.
> spider_net_decode_one_descr() is called from > spider_net_poll() (which is the netdev->poll callback) > and also from spider_net_handle_rxram_full(). > > The rxramfull routine is called from a tasklet that > is fired off after a "RX ram full" interrupt is receved. > This interrupt is generated when the hardware runs out > of space to store incoming packets. We are seeing this > interrupt fire when the CPU is heavily loaded, and a > lot of traffic is being fired at the device. How often does that interrupt happen in that case ? A better approach is to keep the fast path (ie. poll()) lockless, and in handle_rxram_full(), the slow path, protect against poll using netif_disable_poll(). Though that means using a work queue, not a tasklet, since it needs to schedule. > > and what other > > non-sledgehammer approaches were discarded before arriving at this one? > > Well, I'm not that good at kernel programming, so I guess > I did not perceive this as a "sledgehammer." And alternative > approach is to simply ignore the rxramfull interrupt entirely, > and depend on poll() do all the work. I'll try this shortly. or you can schedule rx work from the rxramfull interrupt after setting a "something bad happened" flag. Then, poll can check this flag and do the right thing. Ben. - 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
