Forum Discussion

Matt_Breedlove_'s avatar
Matt_Breedlove_
Icon for Nimbostratus rankNimbostratus
Apr 24, 2011

CMP 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

 

 

 

 

 

4 Replies

  • 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
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    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
  • 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

     

  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    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