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.
Ah, I see. Definitely appears for me in interrupts then. I've got the
mxge driver doing the work here. So, given that I can spread out the
interrupts to every core (like, pin an interrupt queue to each core), I
can have all my cores work on the process. But seeing as though the pf
bit is still serialized I'm not sure that I understand how it is
serialized when many CPUs are handling interrupts, and hence doing the
work of pf as well? Wouldn't that indicate that the work of pf is being
handled by many cores, as many cores are handling the interrupts?
Or are you saying that pf *is* being handled by many cores, but just in
a serialized nature? Like, packet 1 is handled by core 0, then packet 2
is handled by core 1, packet 3 is handled by core 4, etc? Such that
even though multiple cores are handling it, they are just doing so
serially and not in parallel? And if so, maybe it still helps to have
many cores?
Thanks for all the excellent info!
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.
_______________________________________________
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"
