Resource profiles

What is a resource profile?

IOx nodes may have different cpu architectures and characterizing an applications performance or requirements on each of them would become very complex. IOx attempts to bring consistency and uniformity by using a notion of resource profiles.

A Resource Profile encapsulates a set of resources (cpu, memory etc.,) under a unique name in a consistent fashion across all cisco's IOx platforms.

The motive here is to allow developers get some level of consistency when they test their applications on one platform and want to deploy the same on other platforms. Currently, cpu and memory are characterized under a resource profile.

Resource profile definitions

Currently, the following resource profiles are defined. However, the exact set of profiles supported on a platform is a function of the available resources on the platform.

• Memory assignment is platform agnostic and can be directly assigned based on the application requirement irrespective of the platform. However cpu resources is highly platform dependent and performance may vary based on the underlying cpu architecture.

• To abstract this disparate characteristics to application developers and provide a uniform and consistent view, cpu resources are expressed in the form of "units". This means an app with 'x' cpu units would have similar performance on all cisco supported heterogeneous platforms.

• The CPU unit values for a platform is obtained by executing standard benchmarking tools on that platform and assigning a unit value based on their relative score when compared against a standard base platform.

• To get a relative idea of what those units could mean in comparision to a standard cpu, here is a comparision with a generic x86 Intel platform.

  Based on the benchmarking results, x86 based 64 bit Intel Xeon processor with one core of CPU @ 2GHz will have 10000 cpu units. Based on this value developer can extrapolate and test an application in their devnet sandbox environment based out of same CPU characteristics and check the cpu units required for an app.

What resources are available on my device?

Refer to the Platform support matrix for more details.

Choosing an appropriate profile for your app

• Review what profiles are supported in your platform. This will be available via Local Manager / ioxclient.

For ex, using ioxclient:

$ ioxclient platform capability | grep supported_profile_types -A 10         
   "supported_profile_types": [
    "c1.tiny",
    "c1.small",
    "c1.medium",
    "c1.large",
    "default",
    "custom"
   ]
  }
 ],
 "mgmt_api_version": "2.0",

• The definition of each profile is given in the section above.

• To finalize on what exact profile has to be chosen, developer has to validate an app against the given target platform and check what is the maximuim CPU percentage that is consumed.

For instance, if app consumes maximuim of 20 % cpu on 829 platform , then it can be safely assumed that app's requirement for CPU is maximuim of 150 units which is 20% of total CPU units available on the 829 platform in this case. So "c1.small" profile can be asked for in package descriptor file. Needless to say, this also means that the memory requirement is also satisfied with c1.small.

• The same profile can be assigned when an app is deployed on any other platform and the app's performance characteristics should remain largely the same.

• If the standard profile definitions doesn't satisfy an application's requirements, it is possible for the application to ask for a custom profile, under which the app can request for specific values of cpu and memory in 'units' and 'mb' respectively. These values should obviously be within the limits imposed by the platform.

Here is a sample package_descriptor.yaml snippet.

info:
...
...

app:
...
  resources:
    profile: custom
    cpu: 400
    memory: 200

A note about resource bounds

• The cpu units allocated to an app is the minimuim guaranteed. This means that at a given point in time depending upon number of applications running, an app under consideration will get the assured cpu units and may even get more than that if there is no other contention for cpu.

• However, memory is a HARD LIMIT. That is, at no point in time, the app will get more memory than what is allocated. Going beyond this limit typically results in a KILL signal to the application.