IPFW Firewall multithreading ...

Hi all.

Is IPFW multithreading or not ???
I have home small lab :
- small mini pc with one NIC ## routing and shaping on stick ##
- NIC is vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
- cpu is Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz 4x

I see - all shaping and traffic use only one CPU ...
- why ?
# vmstat -i
interrupt                          total       rate
irq4: uart0                         4543          0
irq19: re1                     291691328        215
irq23: ehci1                     2039474          2
cpu0:timer                    1360541921       1001
cpu1:timer                      13007172         10
cpu2:timer                      40205692         30
cpu3:timer                      10972048          8
irq33: ahci0                      701768          119 - not 
Total                         1721203427       1266

cpuset any cpu to irq19 - not work
- all traffic and shaping use still one cpu ...

We can assign irq to multiple cores ??

Any idea ??

sorry for my bad english langue ...


Staff member
SirDice that was an interesting link back up in #2.
Lots of folks don't realize that firewalling/packet filtering is happening in the network stack code path, so already lots of fun when multithreading. Locks all over the place typically.
FreeBSD pf, derived from OpenBSD pf and heavily modified, has done a lot because of multithreading. I'm not sure if ipfw has been modified to deal with it.


Staff member
I'm not sure if ipfw has been modified to deal with it.
I'm honestly not sure, I'm not that familiar with the code. But seeing IPFW is the "native" FreeBSD firewall (both PF and IPFilter were imported) I would presume a lot of work has already been done with FreeBSD 5 when we got a much improved SMP system with a more finely grained locking (no "giant" locks).
Agreed. It always comes down to "how much" and based on the mailing lists that Kristof and others have put a lot of effort into pf. It also boils down to picking the appropriate tool for the workload and perhaps the OP workload is simply too much for ipfw