Hi,
this thread seems it seems to be related to my problem (see High CPU
interrupt load on intekl i350T4 with igb on 8.3). So let me jump in ;)
Le 26/04/2013 17:54, Andre Oppermann a écrit :
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.
That is very interesting. Do you think my High CPU interrupt problem
could be related to the fact that we use pf + altq ?
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.
Would it be possible to use cpu affinity to reserve a core to pf ? For
instance, use only 7 queues per card and keep a core available to pf ?
Does that make sense or would the pf lock impact the interrupts of the
interface queues ? I see a lot of "WAIT" state on the queues when I do a
top -CHSIz.
Cheers,
--
Clément (nodens)
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
