Forum Discussion
Matt_Breedlove_
Nimbostratus
NimbostratusCMP questions on cores/TMM
Read the whitepaper on CMP and the wiki on the constraints of irules with CMP and have some questions....
1) When using a viprion platform (2 viprions, each with a single blade populated in active/standby mode), running 10.1.x, does a VS irule using a global var mean that the VS will only be able to have its connections processed by the first blade on the active viprion chassis or just the first core of the first blade? Each blade has 8 cores
2) Is CMP even activated when using a single blade in a viprion under active/standby mode, even if its a multi-core blade? Does CMP only matter when using more than one blade in an active viprion since the clustered TMM is per blade, not per core/cpu? I assume the CMP'd TMM is per blade not per chassis of viprion blades?
3) Say that in the future that a second blade is added to the active and standby viprion's, and say there are 10 different irules using global var's in their own way. Is the viprion platform smart enough to say, hmm I have 10 different irules that have CMP disabled, so I am going to distribute those equally across the cores/blades on the active viprion chassis or are they all going to be limited to the first core/blade and be stuck there so that first one always runs a little hotter
We use active/standby pairs of LTM only, bot 6400's and Viprions, so does CMP even matter with that HA strategy?
Appreciate the clarifications
Thanks
M
hooleylistCirrostratus
Hi Matt,
Here are some comments. If anyone else has more info or corrections, please pipe in üôÇ
1. A global variable will demote the virtual server from running on more than one CPU core. I think on a Viprion this will be the first CPU on the first blade. You can check this using an iRule:http://devcentral.f5.com/wiki/default.aspx/iRules/TMM__cmp_group.html when RULE_INIT { Set a global variable to demote the virtual server set ::my_global_var "test" Log which slot/CPU we're running on set tmm_unit_cmd TMM::cmp_unit set tmm_group_cmd TMM::cmp_group log local0. "CPU ID: [eval $tmm_unit_cmd], slot: [eval $tmm_group_cmd]" }
2. CMP is potentially enabled whenever the platform has more than CPU core available and the config is CMP compatible.
3. No, I don't believe the mechanism for distributing virtual servers is configurable and they are pinned to the first TMM instance available.
4. CMP only comes into play within the same unit. There isn't any sharing of work across platforms for CMP.
Aaron- Aaron pretty much covered all of your direct questions, but I'll add that the concept of CMP is an important one when talking about performance, so doing anything to disable CMP is something we very much encourage people to avoid.
Global variables just aren't necessary 99% of the time, as there are other, more efficient ways to do most things you would do in a global variable anyway. If you have some specific cases in which you're currently using globals, we can almost certainly help in getting those converted to a more CMP friendly format.
As Aaron pointed out a couple times, CMP is not just across blades, it's across cores, which means it's not just a Viprion concept, it's a concept that's used on most of our multi-core platforms. So yes, even with only one blade it's something that's good to keep in mind.
Colin 
Matt_Breedlove_Thanks for the clarifications. At this point there are only a handful of VS out of 200+ VS's that use an irule exercising an increment/reset gvar. Worst case scenario, with no modification, those particular VS will just run on the first core of the LTM in cmp demoted mode. Since the total LTM cpu utilization is still well below 40% utilization its probably something that can be postponed until things start heating up. It is comforting to know that there is a close to dropin replacement for an "incr ::gvar" with "table incr" just have to take the time to retrofit based on that
Cheers- Excellent, it sounds like you're in an all right place for the time being, but it's definitely something to add to your future slate for possible improvements and performance gains.
Colin
