Date: Thu, 20 Jul 2006 09:36:14 -0600 From: Scott Long <scottl@samsco.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-stable@freebsd.org, Ed Maste <emaste@phaedrus.sandvine.ca> Subject: Re: How to setup polling on 'bge' interface Message-ID: <44BFA2EE.7060308@samsco.org> In-Reply-To: <20060720112613.GB716@turion.vk2pj.dyndns.org> References: <20060711190908.GC69272@registro.br> <20060720023856.GA65960@sandvine.com> <20060720112613.GB716@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > On Wed, 2006-Jul-19 22:38:56 -0400, Ed Maste wrote: > >>- You may have to adjust some parameters in the kern.polling sysctl >> tree - specifically, kern.polling.burst_max, kern.polling.each_burst >> and kern.polling.user_frac might need tweaking. > > > Note that increasing kern.polling.burst_max and kern.polling.each_burst > will also increase the number of soft interrupts. > > >>- The polling feedback algorithm does not work very well if your >> workload is focused largely on per-packet tasks (such as routing or >> bridging). You'll find that there is still idle CPU time at the >> point you start dropping packets. I have some work in progress to >> address this, but it's not yet committed. > > > I thought setting kern.polling.idle_poll would allow the CPU to > utilise all idle time. The downside is that the system always shows > as 100% utilised so it's very difficult to know how busy the system > actually is. > > >>- Polling's major advantage is the avoidance of livelock on UP systems, >> and not improved performance. > > > The limited testing I've done on a Sun V20z at work suggests that you > can get better routing throughput in interrupt mode than polling mode. > YMMV and this is before tweaking the polling parameters. (My testing > also suggests that I don't really need to do any tweaking because > the limiting factor is the gigabit interfaces rather than the V20z). > This might not apply to bge, but the adaptive polling + fast interrupt changes that I made to if_em earlier in the year were a huge win over the standard polling code in terms of CPU utilization and packets per second. I think it also survived a load that caused normal polling to essentially livelock the machine. And, it had the advantage of automatically adapting to bursty loads. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44BFA2EE.7060308>