On Thu, Apr 17, 2008 at 10:31 AM, Robert Watson <[EMAIL PROTECTED]> wrote: > > On Thu, 17 Apr 2008, Alexander Sack wrote: > > > > Robert, alright, this all makes sense. So it seems to me that the first > step to salvation in my world is to turn off DEVICE_POLLING and rely on the > interrupt coalescing that exists on the card. My only concern if this does > work is what impact this has on the overall system. > > > > I would generally discourage use of our current DEVICE_POLLING code using > modern network devices, as the polling rate as compared to buffer size has > changed significantly, meaning that polling rates have to be set > ridiculously high. Also, I suspect strongly that it interacts badly with > our ithread/scheduling/etc parts, which might lead to difficult to diagnose > problems. Interrupt moderation is not as featureful as DEVICE_POLLING, but > it is better supported; I'd like to see further work done to allow us to > pick up some of the scheduling features for ithreads as well in the future.
Gotcha, this is really good to know. FreeBSD is a new OS for me to work on but I'm learning so much everyday! I believe Solaris uses ithreads natively and I do know there are some drivers that forcefully create kernel threads to handle interrupts as way to scale (I have no idea the ramification of this on FreeBSD or if the overhead of creating a new kthread outweighs the benefits). Going to go turn off DEVICE_POLLING and see what happens... -aps _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
