As far as I understand, processing of packets by pf takes place in receiving network card's interrupt handler even up to sending the packet via another network card (at least in my case, when using route-to targets, which make routing inside pf).
That's interesting. So even though pf is giant locked, you can still scale the maximum capacity of your firewall, in this case, simply by adding more CPU cores? To handle the extra interrupts? So more cores = more packets per second, if you give each extra core an additional interrupt queue?
How do you count the 140kpps value? One interface, both, in, out? I'd like to relate this somehow to my values.
Well, generally we see 80kpps rx and 40kpps tx. But I have seen the rx spike to 150kpps occasionally. This is a pfSense box, which includes RRD graphs of packet rates, that's how I'm getting the number. I'm not sure how they are obtaining that metric under the hood. But we have not disabled HT and some other items, so that number will change is my guess. We also may add another CPU die to the mix to see if we can add interrupt queues to more cores to increase performance.
_______________________________________________ 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"
