- Products
- Learn
- Local User Groups
- Partners
- More
The Great Exposure Reset
24 February 2026 @ 5pm CET / 11am EST
CheckMates Fest 2026
Watch Now!AI Security Masters
Hacking with AI: The Dark Side of Innovation
CheckMates Go:
CheckMates Fest
Hi All,
I've just upgraded a 6 member VSX VSLS cluster from R80.10 to R80.40.
Before the upgrade there was no multi-queue or SMT configuration.
Whilst multi-queue was supported on R80.10 because of the ixgbe driver, I did not have it configured.
SMT was well known to not be supported on Openservers, so also not configured.
The hardware for each member is HP ProLiant DL380p Gen 8.
After upgrading to R80.40, to my surprise I suddenly found 32 CPU cores instead of 16 CPU cores, and that every interface had automatic multi-queues.
The documentation suggests that both SMT and multi-queue are items you have to 'decide' to enable.
So, given I've not chosen to enable these myself... Is R80.40 now supporting SMT and automatically enabling it?
Each VSX Gateway in the cluster only has a license for 16 Cores, so I don't know how that affects this also.
cpconfig has no options to disable hyper-threading.
Is anyone else seeing this as a default behaviour?
Is this behaviour to do with the new 'automatic resource allocation' features?
Many thanks,
JD
On Open Servers, virtual cores created by Hyperthreading need to be licensed if you want to use them.
Hyperthreading has to be disabled in the BIOS.
Multiqueue is now enabled by default from R80.40.
Currently (R80.40), license is counting only the physical cores, but in the future we will enforce based on the virtual cores.
Thanks, Guy
We are planning to return the license enforcement back to normal in R81.10.
It will be mentioned in the release notes.
Guy
On Open Servers, virtual cores created by Hyperthreading need to be licensed if you want to use them.
Hyperthreading has to be disabled in the BIOS.
Multiqueue is now enabled by default from R80.40.
Hi @PhoneBoy,
Thanks for the reply. TAC also managed to clarify although what your saying seems at odds with the message they gave me.
TAC have pointed me to:
This seems to read to me that the license for cores is based on REAL cores and not SMT/Hyperthreaded logicals - Especially based on the last line of the SK.
I would appreciate your thoughts on this?
Best regards,
JD
Just to add, I understand now that 3.10 Kernel honours the BIOS setting rather than having a setting to disable/enable SMT/HT in cpconfig. 😃
The licensing issue was discussed a while back here: https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/Does-R80-40-support-HP-DL380-G10/...
Entirely possible this has changed since that discussion took place.
@Guy_Israeli can you clarify as it seems sk156793 contradicts what we've said in the past regarding licensing and Hyper-Therading on Open Servers?
Thank for checking, despite my license being "CPSG-8-C-U CPSG-8-C-U", I have noticed coreXL seems to have put the 16 extra into use from the looks of it in fw ctl affinity -l and mq_mng --show.
Hi,
I would like to add my input and verify all is clear.
Since R80.30 3.10, we do not have any option to disable SMT via code, this is something we aim to change in later versions.
Since open servers did not support SMT up until R80.30 3.10 we added, we created a code in R80.40 jumbo to disable SMT when upgrading for non-R80.30 3.10 via the blink option.
Since VSX currently does not support blink, you received SMT enabled by default.
This is ok and supported now but in case you would like to disable it again and keep the same configuration you did before, you should disable SMT via the BIOS.
In later versions, we will add such support in CLI.
Regarding Multi-Q, as was already answered below, supported by default
Can you confirm the licensing issue (i.e. will an 8 core Open Server license officially support 16 cores with SMT enabled)?
Currently (R80.40), license is counting only the physical cores, but in the future we will enforce based on the virtual cores.
Thanks, Guy
@Guy_Israeli thank you for the reply.
Can you advise on when R&D would be looking to change this?
I do not wish to be stung by applying a JHF or a major update and not realise this is being changed.
We are planning to return the license enforcement back to normal in R81.10.
It will be mentioned in the release notes.
Guy
@Guy_Israeli thank you for clarifying.
Knowing this allows me to better plan for future.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 30 | |
| 27 | |
| 11 | |
| 10 | |
| 6 | |
| 6 | |
| 5 | |
| 5 | |
| 5 | |
| 4 |
Thu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesThu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY