Yesterday I pushed a patch that changes the default runmode from “auto” to “autofp”. The autofp name stands for “auto flow pinning” and it automatically makes sure all packets belonging to a flow are processed by the same stream, detection and output thread. Until now, the assignment was done with a simple hash calculation. The problem with that is that it doesn’t take into account how busy a thread may be.

OISF’s Anoop Saldanha recently wrote a new load balancer, called “active-packets”, which is now the default. Before assigning a new flow to a thread, it checks how busy it is. This leads to a much more fair distribution of flows and packets.

AutoFP - Total flow handler queues - 6
AutoFP - Queue 0 - pkts: 82879145 flows: 30589
AutoFP - Queue 1 - pkts: 36997716 flows: 4042
AutoFP - Queue 2 - pkts: 22168624 flows: 356
AutoFP - Queue 3 - pkts: 36886948 flows: 40
AutoFP - Queue 4 - pkts: 22135664 flows: 118
AutoFP - Queue 5 - pkts: 22121314 flows: 101

In the example above it’s clearly visible that the number of flows assigned to queues (and thus threads) varies greatly. However the number of packets varies much less. It may appear that Queue 0 is somewhat oversubscribed, but remember that the queue is selected based on how busy it is. In this case the IDS box is not very busy, so queue 0 was available most of the time.

The output above is displayed at shutdown if you use the (now default) “autofp” mode. Take a look at it to see if the load balancing makes sense in your setup!