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 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.
(4) Limitations
Unsupported operating systems:
IPSO OS is not supported.
Unsupported platforms:
Open Servers are not supported. See sk156793 regarding licensing on Open Servers.
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.
Connect to the command line on the Security Gateway (over SSH, or console).
Log in to the 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'
Enabled
SMT is enabled in BIOS and in 'cpconfig'
*Note: Also can check using: /sbin/cpuinfo
(6) To enable SMT
Examine the current number of CoreXL Firewall instances:
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):
Value
Explanation
fwmultik_dispatch_skip_global=0
This is the default value. CoreXL Firewall instance 0 will also handle the "regular" traffic like any other CoreXL FW instance.
fwmultik_dispatch_skip_global=1
CoreXL Firewall 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 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.
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.
Important - Starting from Linux Kernel version 3.10 (R80.20 kernel 3.10, R80.30 kernel 3.10, R80.40 and higher), SMT (HyperThreading) is enabled by default in BIOS, and users cannot disable it from the 'cpconfig' menu. Disabling SMT is done only in BIOS by Check Point Support. See sk172304 - SMT (HyperThreading) is enabled after an upgrade to R80.40 or higher.
When disabling SMT, the number of CoreXL Firewall 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 a cluster environment, this procedure must be performed on all cluster members.
Notes:
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 Firewall 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).
Enabling SMT will load additional CoreXL Firewall instances. These instances consume memory and the maximal connection capacity may decrease by up to 10%.
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".
