I'm away from my FreeBSD machines at the moment so can't provide much real help, but I will say, for a packet test like this, hyperthreads don't usually help and often hurt. But I thought most of the FreeBSD intel drivers will set up at least as many NIC queues as threads by default, assuming the NIC can manage that many. The quad 1G nics might only do 4 queues (I'm not super familiar with all the limits there), but ix and ixl should do 8 if that's what you want to do.
Might have to tweak the driver options, which would probably be set in /boot/loader.conf and need a reboot.
I'd imagine freebsd-net should be pretty helpful too, of course.
VPP dev here. Our perf tests for Intel run in CSIT lab consistently shows a perf benefit of 10%-20% since Haswell I believe, so in our typical VPP deployment we usually map 2 VPP workers (dataplane threads) to both hyperthreads of the same physical core.
But that's for VPP, your mileage may vary depending of your workload (eg. FreeBSD kernel stack).
Comments
I'm away from my FreeBSD machines at the moment so can't provide much real help, but I will say, for a packet test like this, hyperthreads don't usually help and often hurt. But I thought most of the FreeBSD intel drivers will set up at least as many NIC queues as threads by default, assuming the NIC can manage that many. The quad 1G nics might only do 4 queues (I'm not super familiar with all the limits there), but ix and ixl should do 8 if that's what you want to do.
Might have to tweak the driver options, which would probably be set in /boot/loader.conf and need a reboot.
I'd imagine freebsd-net should be pretty helpful too, of course.
VPP dev here. Our perf tests for Intel run in CSIT lab consistently shows a perf benefit of 10%-20% since Haswell I believe, so in our typical VPP deployment we usually map 2 VPP workers (dataplane threads) to both hyperthreads of the same physical core. But that's for VPP, your mileage may vary depending of your workload (eg. FreeBSD kernel stack).
VPP (tnsr) and FreeBSD (pfsense) user / dev here.
The FreeBSD scheduler is at fault here. It’s that simple.