Hyper-threading and Multi-queue on VSX R80.10

[Kaspars_Zibarts]

Planning our VSX appliance upgrade from 13800 to 23800 and having dilemma if I should enable SMT (aka Hyper-Threading) on the new appliances. We disabled it on the old ones originally as we were not running any advanced blades on any of VSes except IA. Plus one of the VSes does quite a bit of NAT - both go "against" SMT.

We also run Multi-queue on some interfaces, which would mean that I would have to increase number of cores for multi-queue as it would run across hyper-thread cores.

Which kind of pushed me back to re-think and most likely to disable SMT and stick with real cores instead. We still gain 8 cores and that's a lot.

This would be typical Timothy Hall question

[Timothy_Hall]

On a typical non-VSX bare-metal firewall given the limited blades you have enabled, leaving SMT/Hyperthreading disabled would probably be the right call; mainly because there would be a large percentage of traffic being fully accelerated by SecureXL.  Most of the load would be on the SND/IRQ cores and SMT/Hyperthreading doesn't really benefit those cores much on a regular firewall, and can actually hurt performance in some situations like this: Firewall priority queues setting 

But since VSX is more or less a process-based implementation of the inspection that is typically handled in the kernel on a regular firewall, I'd think that enabling SMT/Hyperthreading for VSX would actually be helpful assuming you have plenty of RAM.  Whenever there are numerous process threads all competing for limited cores, SMT/Hyperthreading can permit threads to jump on a core while other threads block waiting for some kind of event.  Since it is a gateway and not an SMS, there is little disk I/O interaction and the usual recommendation to leave SMT/Hyperthreading off on a R80.10 SMS is not relevant here.

This is a bit of an educated guess and I'm definitely not a VSX expert, so I would welcome input from someone at Check Point on this topic with more knowledge of VSX internals.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Kaspars_Zibarts]

Great! Thanks for the that! Here's the question. If we have 4 cores in current non SMT setup allocated for MQ/SXL would you say it would make sense to allocate 8 hyperthreaded cores on the new boxes? From memory SXL doesn't really gain from hyperthreading.

[Timothy_Hall]

If you are sure most of the traffic will be fully accelerated by SecureXL, then yes enabling SMT/Hyperthreading doesn't help and may hurt.  Hard to predict how much traffic will be fully accelerated though, until you actually set up a system and pass your production traffic through it.  For further VSX tuning tips might I suggest this excellent document by Michael Endrizzi:

VSX & CoreXL Training- You’ll love the price | DreezSecurityBlog 

Particularly slides 226 & 227 which make some good default recommendations for initial VSX tuning setups.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Kaspars_Zibarts]

Sorry, I probably wasn't quite clear in the original description - we have one "big" VS that handles 90% of all traffic on that VSX and bunch of smaller ones that doesn't even have CoreXL turned on as there's no need for it. The big one accelerates 96% of the traffic. So it's not really a new unknown setup - we know what to expect  and we're fairly happy with current core performance/balance. The question was theoretical around switching to SMT. Or should we follow good old "if it ain't broke, don't fix it"

[Ross_Pember]

Hi Kaspars

In my playing with VSX and tuning it for various traffic loads I'd say if you're just doing FW and IA and you're happy with how it was running on the 13800s, scaling that same core split up to the amount of cores in the 23800 and leaving hyper-threading off for now would be the way to go. If you plan to enable more blades and increase the amount of CoreXL threads per VS then it might be a time to look at it, but you can enable it later without too much impact - because the VSs are user mode threads and won't change their config when you enable it, you can turn it on on one box, reboot it, and sync will still work because the actual CoreXL per VS settings haven't changed - as long as CoreXL is disabled on VS0 anyway (which it should be).

[Kaspars_Zibarts]

Hehe, good to see you here buddy! It's been long time.. yeah we have both in place - some VSX running with SMT and some without.. might stick with current setup to simplify upgrade and change later if really needed. Thanks for the input all