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 Check Point Appliances.
SMT is supported only on Security Gateways running Gaia OS with 64-bit kernel.
SMT is supported by R77 release and later.
On 23900 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 "Installation and Upgrade Guide" (R77) - Chapter "Upgrading ClusterXL Deployments". 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 FW 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 R77 Performance Tuning Administration Guide - Chapter 3 'Multi-queue'.
(4) Limitations
Unsupported operating systems:
IPSO OS is not supported.
Unsupported platforms:
Open Servers are not supported. Please see sk156793 regarding licensing on Open Servers.
SMT is not recommended if these blades/features are enabled:
Data Loss Prevention blade
Anti-Virus in Traditional Mode
Using Services with Resources in Firewall policy
Reason: Each of these blades might have high memory consumption. These blades run Security Servers that are executed per CoreXL FW instance. Since SMT adds more CoreXL FW 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 FW instances. When more CoreXL FW instances are running, fewer ports for Hide NAT will be available for each CoreXL FW instance. As a result, if one CoreXL FW instance is handling a high number of NATed connections, its port range may get exhausted, while at the same time, other CoreXL FW instances may have enough available ports for Hide NAT.
For more information, refer to the "Checking Gateway Status" section.
If only the Firewall blade is enabled (and no other blades), and you decide to enable the SMT, then performance optimization might be required on your appliance - consult with Check Point Support.
Connect to the command line on the Security Gateway (over SSH, or console).
Log in to Expert mode.
Check the SMT status:
[Expert@HostName:0]# cat /proc/smt_status
Possible output
Explanation
Unsupported
Either SMT is not supported on this machine (refer to "Supported configurations" section), or SMT is disabled in the BIOS (contact Check Point Support to enable the feature in the BIOS)
Soft Disable
SMT is enabled in the BIOS, but disabled in 'cpconfig'
On 6500 / 6800 appliances, SMT is already enabled in the BIOS.
Check the new number of CoreXL FW instances:
[Expert@HostName:0]# fw ctl multik stat
If the number of CoreXL FW instances did not increase automatically, then configure the CoreXL manually:
Run the cpconfig command.
Choose the 'Configure Check Point CoreXL' option.
Set the desired number of CoreXL FW 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 FW 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 above include Multi-Core support for VPN - sk118097): If the VPN 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):
Value
Explanation
fwmultik_dispatch_skip_global=0
This is the default value. CoreXL FW instance 0 will also handle the "regular" traffic like any other CoreXL FW instance.
fwmultik_dispatch_skip_global=1
CoreXL FW instance 0 will not handle any traffic other than VPN / VoIP / IP Pool NAT traffic.
fwmultik_dispatch_skip_global=2
Important Note: Relevant only for Check Point Appliances when working with SMT (HyperThreading) Feature per sk93000.
CoreXL FW instance 0 and CoreXL FW instance 1 share the same physical CPU core. In such an environment, it is recommended to use this value:
CoreXL FW instance 0 will not handle any traffic other than VPN / VoIP / IP Pool NAT traffic
CoreXL FW instance 1 will not handle the "regular" traffic, allowing CoreXL FW 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 FW 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 a 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.
Important note:
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.
When disabling SMT, the number of CoreXL FW instances will decrease automatically.
Run cpconfig.
Choose 'Configure Hyper-Threading' option.
Select 'yes' to disable SMT. The wizard will disable SMT and update the CoreXL automatically.
Press Enter to continue.
Reboot the appliance.
In cluster environment, this procedure must be performed on all cluster members.
Notes:
From Linux Kernel version 3.10 and above, there is no software mechanism that can disable SMT. Disabling SMT is done solely via BIOS configuration.
When disabling SMT, the interfaces affinity is reset to default (automatic affinity).
When SMT is disabled in 'cpconfig', it is not necessary to disable SMT in the BIOS, unless you intend to install a release earlier than R77.
(8) Checking Gateway Status
Before enabling SMT, follow the instructions in this section to verify that the Security Gateway can support SMT safely.
Notes:
This section does not apply to 5800 / 5900 / 6500 / 6800 / 15400 / 15600 / 23500 / 23800 / TE250X / TE1000X / TE2000X appliances, which were tested with SMT enabled.
The section uses a heuristic approach.
These steps are not required on a VSX Gateway (enabling SMT on a VSX Gateway does not increase memory consumption).
Procedure:
Run the cpsizeme tool during peak traffic periods (refer to sk88160) and follow this procedure:
Enter Expert mode.
Run ./cpsizeme
Select option 3 "Run the utility without sending the data automatically to Check Point"
Run ./cpsizeme -S to show summary. The amount of free memory is displayed in the "Minimum Free Memory:" line.
The "Minimum Free Memory" counter should show these values at least:
Appliance
Memory
12400
1.5 GB
12600 21400
3 GB
13500 13800 21600 21700 21800
5 GB
Notes:
These are only guidelines. There may be cases where a lower amount of free memory is sufficient, and vice versa.
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 FW workers.
[Expert@HostName:0]# fw ctl affinity -l -v -r
Example:
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 1:
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 20:
CPU 21:
CPU 22:
CPU 23:
CPU 24:
CPU 25:
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
To make this configuration survive reboot, add the above taskset_us_all -l ... command as a new line at the end of $FWDIR/scripts/fwaffinity_apply script.
Interfaces will be affined to different physical CPU cores (rather than different logical CPU cores on the same physical CPU core).
In the example above (see output of "fw ctl affinity -l -v -r" command above), it is better to affine:
eth4-01 to CPU 0
eth4-05 to CPU 1
(CPU0 and CPU1 are 2 different physical CPU cores), rather than:
eth4-01 to CPU 0
eth4-05 to CPU 20
(CPU0 and CPU20 share the same physical CPU core), or
eth4-01 to CPU 1
eth4-05 to CPU 21
(CPU1 and CPU21 share the same physical CPU core).
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".
