Re: [PATCH 3/16] Spidernet RX Locking

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.

quoted

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.