For gateways with the "typical" blades enabled (APCL, URLF, TP, etc.) SMT/Hyperthreading improves performance since the bulk of traffic tends to end up in the PSLXL path, and to a lesser degree the CPASXL path. Processing in these paths tends to be operations that wait or block often for some event to occur such as the next packet in an inspected stream to arrive. This type of workload benefits from SMT, as once a worker instance on a physical core blocks, another worker instance can hop onto the same physical core via the other thread to get its work done. As such SMT is enabled by default on all Check Point appliances since it is beneficial to performance in most deployments.
But the workload of the SND/IRQ cores is quite different and consists of fast, efficient, rapid-fire operations that are over quickly and perform very little waiting/blocking. If a large percentage of traffic is fully accelerated by SND/SecureXL via tuning adjustments, use of minimal blades (such as only Firewall and IPSec VPN), or utilization of fast_accel, under high load with SMT enabled the two SND/IRQ instances tend to fight each other for the same physical core and decrease performance. In the third edition of my book I state that if 70% or more of traffic is fully accelerated, it is essentially a no-brainer to turn off SMT; however I've seen noticeable improvement even down to only 50% or so of fully accelerated traffic. The percentage of fully accelerated traffic can be assessed by running fwaccel stat and looking at the "Accelerated pkts/Total pkts" line.
Note that if the percentage of fully accelerated traffic changes substantially due to configuration changes it may be desirable to turn SMT back on.
New 2-day Live "Max Power" Series Course Now Available:
"Gateway Performance Optimization R81.20" at maxpowerfirewalls.com