SMT (also called HyperThreading or HT) is a feature that is supported on Check Point appliances running Gaia OS. When enabled, SMT doubles the number of logical CPUs on the Security Gateway, which enhances physical processor utilization. When SMT is disabled, the number of logical CPUs equals the number of physical cores.
SMT improves performance up to 30% on NGFW software blades such as IPS, Application & URL Filtering and Threat Prevention by increasing the number of CoreXL FW instances based on the number of logical CPUs.
(2) Supported configurations
SMT is supported only on Security Gateways running Gaia OS with 64-bit kernel.
SMT is supported on the following releases:
On Check Point Appliances, SMT is supported by R77 release and later.
On Open Servers, SMT is supported by R80.40 Jumbo HF #45 and later, and the CPU must also support SMT.
On23900 appliances running R80.20 with Jumbo Hotfix Take 33 and above, SMT is supported when USFW is enabled. The limitations below regarding QoS and DLP do not apply to 23900 appliances when USFW is enabled. For instructions on how to enable USFW, refer to sk167052. Starting from R80.30, USFW is enabled by default.
In ClusterXL environments, this procedure must be performed on all members of the cluster. Refer to the "Installation and Upgrade Guide" for your version. Note: "Full Connectivity Upgrade" is not supported.
Changing SMT state (enabling/disabling) requires reboot.
When enabling SMT on a Security Gateway, refer to the "Checking Gateway Status" section to verify the available memory to support the additional CoreXL Firewall instances.
If you have two ports on any of the aforementioned appliances to handle most of the traffic, it is recommended to enable the Multi-Queue feature to increase SMT performance. For the procedure to enable Multi-Queue, refer to the Performance Tuning Administration Guide for your version - Chapter Multi-Queue.
SMT is not recommended if these Software Blades / Features are enabled:
Data Loss Prevention blade
Anti-Virus in Traditional Mode
Using Services with Resources in Firewall policy
Reason: Each of these Software Blades / Features might have high memory consumption. These Software Blades / features run Security Servers that are executed in each CoreXL Firewall instance. Because SMT adds more CoreXL Firewall instances, the overall memory consumption on the Security Gateway might increase considerably.
SMT is not recommended for environments that use Hide NAT extensively.
Reason: An entire range of ports for Hide NAT is divided between the current CoreXL Firewall instances. When more CoreXL Firewall instances are running, fewer ports for Hide NAT will be available for each CoreXL Firewall instance. As a result, if one CoreXL Firewall instance is handling a high number of NATed connections, its port range may get exhausted, while at the same time, other CoreXL Firewall instances may have enough available ports for Hide NAT.
For more information, refer to the "Checking Gateway Status" section.
If only the "Firewall" Software Blade is enabled (and no other Software Blades), and you decide to enable the SMT, then performance optimization might be required on your appliance - consult with Check Point Support.
On 6500 / 6800 appliances, SMT is already enabled in the BIOS.
Examine the new number of CoreXL Firewall instances:
[Expert@HostName:0]# fw ctl multik stat
If the number of CoreXL Firewall instances did not increase automatically, then configure the CoreXL manually:
Run the cpconfig command.
Choose the 'Configure Check Point CoreXL' option.
Configure the desired number of CoreXL Firewall instances.
Reboot the appliance.
Configure Hyper-Threading (SMT):
Run the cpconfig command.
Choose the 'Configure Hyper-Threading' option.
Select 'yes' to enable SMT.
The wizard enables SMT and updates the number of CoreXL Firewall instances automatically. If the wizard cannot update CoreXL automatically, then configure the CoreXL manually as described above (this is relevant in cases where CoreXL configuration was modified manually before enabling SMT).
Press Enter to continue.
On R77 / R77.10 / R77.20 / R77.30 versions only (R80.10 and higher, include the Multi-Core support for VPN - sk118097): If the VPN Software Blade is enabled and a significant amount of IPSec VPN traffic passes through the Security Gateway / ClusterXL, then follow these steps:
When you enable SMT, permanently set the value of the kernel parameter fwmultik_dispatch_skip_global to 2 (per sk26202):
This is the default value. CoreXL Firewall instance 0 will also handle the "regular" traffic like any other CoreXL FW instance.
CoreXL Firewall instance 0 will not handle any traffic other than VPN / VoIP / IP Pool NAT traffic.
Important Note: Relevant only for Check Point Appliances when working with SMT (HyperThreading) Feature per sk93000.
CoreXL Firewall instance 0 and CoreXL Firewall instance 1 share the same physical CPU core. In such an environment, it is recommended to use this value:
CoreXL Firewall instance 0 will not handle any traffic other than VPN / VoIP / IP Pool NAT traffic
CoreXL Firewall instance 1 will not handle the "regular" traffic, allowing CoreXL Firewall instance 0 to better utilize the physical CPU core.
Important Note (Issue ID 01532511):IPv6 traffic is incorrectly dropped when the value of kernel parameter fwmultik_dispatch_skip_global is greater than or equals the number of configured CoreXL IPv6 FW instances - in such a case, CoreXL SND can not find a CoreXL IPv6 Firewall instance to which the traffic can be forwarded, so it drops it. Kernel debug ('fw ctl debug -m multik + packet' and 'fw ctl debug -m fw + drop') shows:
;[cpu_0];[fw6_0];fwmultik_dispatch_outbound: Packet on gconn < ... IPP 58 > goes to vsid 0 fw_N, reason arbitrary (offset 0, ifnum Z); ;[cpu_0];[fw6_0];fwmultik_dispatch_outbound: No instance on outbound dropping (vsid 0, instance N, num of instances N, dispatch reason arbitrary); ;[cpu_0];[fw6_0];fw_log_drop_ex: Packet proto=58 ... dropped by fwmultik_dispatch_outbound Reason: No instance (outbound);
For R77 / R77.10 / R77.20, contact Check Point Support to get the Hotfix for Issue ID 01532511 (IPv6 traffic being incorrectly dropped). This hotfix is already integrated into R77.30. A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix. For faster resolution and verification, please collect CPinfo files from the Security Management Server and Security Gateway involved in the case.
Hotfix has to be installed on Security Gateway. Note: In cluster environment, this procedure must be performed on all members of the cluster.
Transfer the hotfix package to the Security Gateway (into some directory, e.g., /some_path_to_fix/).
Unpack and install the hotfix package:
[Expert@HostName:0]# cd /some_path_to_fix/ [Expert@HostName:0]# tar -zxvf fw1_wrapper_<HOTFIX_NAME>.tgz [Expert@HostName:0]# ./fw1_wrapper_<HOTFIX_NAME>
Note: The script will stop all of Check Point services (cpstop) - read the output on the screen.
Reboot the Security Gateway.
Check the current value of kernel parameter:
[Expert@HostName:0]# fw ctl get int fwmultik_dispatch_skip_global
Create the $FWDIR/boot/modules/fwkern.conf file (if it does not exist):
When you disable SMT (after enabling it), we recommend that you change the value of kernel parameter 'fwmultik_dispatch_skip_global' back to its original value as seen in Step 5-A-ii, or delete the 'fwmultik_dispatch_skip_global=2' line from the $FWDIR/boot/modules/fwkern.conf file.
Note: When upgrading your appliance, you need to repeat Step 5-A.
Reboot the appliance.
In cluster environment, this procedure must be performed on all cluster members.
When installing a release R76 and lower on an appliance (excluding 13500 appliance), it is mandatory to disable SMT in the BIOS if it was enabled. Otherwise, the results are unexpected, and you may experience installation or functionality issues later on.
The "Estimated average of NAT connections" counter should show less than 50%.
(9) SMT Best Practices
For the best performance, it is recommended that:
User space processes not be affined to the same physical CPU core as the Secure Network Distributors (SNDs), but rather that they be affined to the Firewall workers CPUs (refer to sk98737 - ATRG: CoreXL for more information):
Identify CPUs which run CoreXL Firewall workers.
[Expert@HostName:0]# fw ctl affinity -l -v -r
In this example, CPUs 2-19, 26-39 run CoreXL FW workers.
[Expert@HostName:0]# fw ctl affinity -l -v -r
CPU 0: eth4-01 (irq 234) eth4-05 (irq 123) Mgmt (irq 187)
CPU 2: fw_31
CPU 3: fw_30
CPU 4: fw_29
CPU 5: fw_28
CPU 6: fw_27
CPU 7: fw_25
CPU 8: fw_23
CPU 9: fw_21
CPU 10: fw_19
CPU 11: fw_17
CPU 12: fw_15
CPU 13: fw_13
CPU 14: fw_11
CPU 15: fw_9
CPU 16: fw_7
CPU 17: fw_5
CPU 18: fw_3
CPU 19: fw_1
CPU 26: fw_26
CPU 27: fw_24
CPU 28: fw_22
CPU 29: fw_20
CPU 30: fw_18
CPU 31: fw_16
CPU 32: fw_14
CPU 33: fw_12
CPU 34: fw_10
CPU 35: fw_8
CPU 36: fw_6
CPU 37: fw_4
CPU 38: fw_2
CPU 39: fw_0
All: mpdaemon in.geod fwd cprid cpd
The 'cpsizeme' tool (see sk88160) can help determine if it is safe to enable SMT. For more details, refer to the "Checking Gateway Status" section of this article. Note that the section uses a heuristic approach.
After enabling SMT and rebooting, you can run the 'cpsizeme' tool again to verify that the minimal free memory has not decreased to 0% or close to 0%. Regarding NAT, you should verify that the following log does not appear in the SmartView Tracker: "NAT Hide failure - there are currently no available ports for hide operation".