Support Center > Search Results > SecureKnowledge Details
SMT (HyperThreading) Feature Guide Technical Level
Solution

Table of Contents:

  1. Overview
  2. Supported configurations
  3. Notes
  4. Limitations
  5. To check SMT current status
  6. To enable SMT
  7. To disable SMT
  8. Checking Gateway Status
  9. SMT Best Practices
  10. Frequently Asked Questions

 

(1) Overview

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.

  • Supported appliance configurations:

    Appliance Comments
    6200
    6600
    6700
    6900
    7000
    16000
    16200
    16600
    26000
    28000
    28600HS
    • Hyper-threading is enabled in the BIOS.
    • Note: 6400 and 6600 does not support SMT on the CPU.  
    12400 Requires 8 GB of RAM.
    Refer to these solutions:
    • sk68700 for instructions for "12400 Appliance Installing and Removing Memory"
    • sk71001 for instructions on how to upgrade to 64-bit Gaia computers
    Requires enabling of SMT feature both in the BIOS and in 'cpconfig' (refer to "To enable SMT" section).
    12600 Requires enabling of SMT feature both in the BIOS and in 'cpconfig' (refer to "To enable SMT" section).
    13500
    13800

    Is already shipped with enabled SMT feature in the BIOS.

    Requires enabling of SMT feature only in 'cpconfig' (refer to "To enable SMT" section).
    21400
    21600
    21700

    SAM Acceleration card is not supported.

    Requires enabling of SMT feature both in the BIOS and in 'cpconfig' (refer to "To enable SMT" section).
    5800
    5900
    15400
    15600
    23500
    23800

    Is already shipped with enabled SMT feature in the BIOS.

    5800 / 15400 / 15600 / 23500 / 23800 appliances require:
    1. Installation of the hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization.
    2. Enabling of SMT feature in 'cpconfig' (refer to "To enable SMT" section).

    On 5800 / 5900 / 15400 / 15600 / 23500 / 23800 appliances, SMT is recommended with all blades.

    TE250X
    TE1000X
    TE2000X
    TE2000XN

    Is already shipped with enabled SMT feature in the BIOS.

    Requires enabling of SMT feature only in 'cpconfig' (refer to "To enable SMT" section).

    On these appliances, SMT is recommended with all blades.

    6500
    6800
    Is already shipped with enabled SMT feature in the BIOS.

    Requires enabling of SMT feature only in 'cpconfig' (refer to "To enable SMT" section).

    On these appliances, SMT is recommended with all blades.
    2200 SMT Hyper-Threading in the BIOS is on by default, 

    Note: To enable SMT in the BIOS, contact Check Point Support or contact Check Point Professional Services to get confirmation and approval beforehand.

 

(3) Notes

  • 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:

    • See sk156793 regarding licensing on Open Servers.
    • IP Series appliances are not supported.
  • Gaia Backup & Restore does not support the SMT (HyperThreading):

    1. Before performing the restore procedure, disable the SMT
    2. Perform the restore procedure
    3. Enable the SMT
    4. Follow the SMT Best Practices
           Note : This is not applicable for the Gaia OS kernel 3.10 version.
  • QoS is supported starting from R77.10.  

    Exception: This limitation does not apply to 5800 / 5900 / 15400 / 15600 / 23500 / 23800 appliances with the installed hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization.

  • 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.

    Exception: This limitation does not apply to 5800 / 15400 / 15600 / 23500 / 23800 appliances with the installed hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization.

  • 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.

    Show / Hide details

    Refer to sk88160 - Dynamic NAT port allocation feature to mitigate this limitation.

    The port distribution is based on the following factors:

    • Number of CoreXL Firewall instances
    • Whether cluster is enabled
    • Whether SecureXL is enabled
    • Whether VPN blade is enabled

    To check the extent of NAT on the Security Gateway, use the cpsizeme tool (refer to sk88160):

    1. Run the tool for at least 24 hours.
    2. Run the 'cpsizeme -S' command.
    3. Select option 2 "Show summary of last successful session" (to see the summary of the collected statistics).
    4. Check the "Estimated average of NAT connections:" counter.

    Exception: This limitation does not apply to 5800 / 15400 / 15600 / 23500 / 23800 appliances with the installed hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization. On 5800 / 5900 / 15400 / 15600 / 23500 / 23800 appliances, it is recommended to follow sk103656 - Dynamic NAT port allocation feature.

    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.

    Exception: This limitation does not apply to 5800 / 15400 / 15600 / 23500 / 23800 appliances with the installed hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization.

 

(5) To check SMT current status

  1. Connect to the command line on the Security Gateway (over SSH, or console).

  2. Log in to the Expert mode.

  3. 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

  1. Examine the current number of CoreXL Firewall instances:

    [Expert@HostName:0]# fw ctl multik stat
  2. Enable SMT in the BIOS:


    • On 6500 / 6800 appliances, SMT is already enabled in the BIOS.
  3. 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:

    1. Run the cpconfig command.
    2. Choose the 'Configure Check Point CoreXL' option.
    3. Configure the desired number of CoreXL Firewall instances.
    4. Reboot the appliance.
  4. Configure Hyper-Threading (SMT):

    1. Run the cpconfig command.
    2. Choose the 'Configure Hyper-Threading' option.
    3. Select 'yes' to enable SMT.
    4. 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).
    5. Press Enter to continue.
  5. 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:

    1. 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);
      1. 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.

        1. Hotfix has to be installed on Security Gateway.
          Note: In cluster environment, this procedure must be performed on all members of the cluster.

        2. Transfer the hotfix package to the Security Gateway (into some directory, e.g., /some_path_to_fix/).

        3. 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.

        4. Reboot the Security Gateway.
      2. Check the current value of kernel parameter:

        [Expert@HostName:0]# fw ctl get int fwmultik_dispatch_skip_global
      3. Create the $FWDIR/boot/modules/fwkern.conf file (if it does not exist):

        [Expert@HostName:0]# touch $FWDIR/boot/modules/fwkern.conf
      4. Check the current contents of the $FWDIR/boot/modules/fwkern.conf file (if the files already existed):

        [Expert@HostName:0]# cat $FWDIR/boot/modules/fwkern.conf
      5. Edit the $FWDIR/boot/modules/fwkern.conf file in Vi editor:

        [Expert@HostName:0]# vi $FWDIR/boot/modules/fwkern.conf
      6. Add the kernel parameter fwmultik_dispatch_skip_global with a new value of 2 (spaces are not allowed):

        fwmultik_dispatch_skip_global=2
      7. Save the changes in the file and exit from Vi editor.

      8. Check the new contents of the $FWDIR/boot/modules/fwkern.conf file:

        [Expert@HostName:0]# cat $FWDIR/boot/modules/fwkern.conf

    2. 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.

  6. Reboot the appliance.

  7. 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.

Contact Check Point Support or contact Check Point Professional Services in order to disable the feature in the BIOS.

 

(7) To disable SMT

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.

  1. Run cpconfig.

  2. Choose 'Configure Hyper-Threading' option.

  3. Select 'yes' to disable SMT. The wizard will disable SMT and update the CoreXL automatically.

  4. Press Enter to continue.

  5. Reboot the appliance.

  6. 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:

  1. Run the cpsizeme tool during peak traffic periods (refer to sk88160) and follow this procedure:

    1. Enter Expert mode.
    2. Run ./cpsizeme
    3. Select option 3 "Run the utility without sending the data automatically to Check Point"
  2. Run ./cpsizeme -S to show summary. The amount of free memory is displayed in the "Minimum Free Memory:" line.

  3. 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:

  4. 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):

    1. 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
      
    2. Affine all user space processes to those CPUs:

      [Expert@HostName:0]# taskset_us_all -l CPU_ID1,CPU_ID2,...CPU_IDx-CPU_IDy

      Example (based on the output in Step A):

      [Expert@HostName:0]# taskset_us_all -l 2-19,26-39
      
    3. 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).

 

(10) Frequently Asked Questions

Applies To:
  • 01532511 , 01532943 , 01536882

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment