Date: Fri, 26 Apr 2013 17:54:31 +0200 From: Andre Oppermann <andre@freebsd.org> To: Erich Weiler <weiler@soe.ucsc.edu> Cc: freebsd-net@freebsd.org Subject: Re: pf performance? Message-ID: <517AA337.8050505@freebsd.org> In-Reply-To: <517A93FE.7020209@soe.ucsc.edu> References: <5176E5C1.9090601@soe.ucsc.edu> <20130426134224.GV76816@FreeBSD.org> <517A93FE.7020209@soe.ucsc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26.04.2013 16:49, Erich Weiler wrote: >> The pf isn't a process, so you can't see it in top. pf has some helper >> threads however, but packet processing isn't performed by any of them. > > But the work pf does would show up in 'system' on top right? So if I see all my CPUs tied up 100% > in 'interrupts' and very little 'system', would it be a reasonable assumption to think that if I got > more CPU cores to handle the interrupts that eventually I would see 'system' load increase as the > interrupt load became faster to be handled? And thus increase my bandwidth? Having the work of pf show up in 'interrupts' or 'system' depends on the network driver and how it handles sending packets up the stack. In most cases drivers deliver packets from interrupt context. > In other words, until I see like 100% system usage in one core, I would have room to grow? You have room to grow if 'idle' is more than 0% and the interrupts of the networks cards are running on different cores. If one core gets all the interrupts a second idle core doesn't get the chance to help out. IIRC the interrupt allocation to cores is done at interrupt registration time or driver attach time. It can be re-distributed at run time on most architecture but I'm not sure we have an easily accessible API for that. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?517AA337.8050505>