DEVICE_POLLING with SMP

[Kevin Day]

On Jan 29, 2004, at 1:04 AM, Vlad Galu wrote:
>
> 	I see no reason for it. Having to switch between multiple kernel
> threads to handle polling may bring too much overhead.
>
>

Would that really be happening though?

If polling is happening in the idle loop, extra overhead doesn't really 
matter all that much, the CPU is idle, and I can't imagine it being any 
worse during a livelock inducing amount of traffic.

If it's polling during any other time, the code is exactly the same 
between the UP and SMP case, and I can't imagine the overhead being all 
THAT much worse, would it?

My primary goal with it is to stop thrashing context switches when I've 
got a system acting as a router with 8 network interfaces on it. Even 
with network card interrupt coalescing there is a whole lot of 
interrupt activity going on, which polling seems to make a noticeable 
difference with polling enabled. I'm also very interested in polling's 
ability to more gracefully handle extremely heavy network traffic 
without getting into livelock, which may be worth it to some people 
prone to DoS activity when they have a whole lot of bandwidth to deal 
with.

I'd be willing to chip in a few bucks for development time if anyone 
wants to make the changes to try it out. It didn't look that difficult, 
but my time is pretty booked right now.

-- Kevin