Documentation/ckrm/rbce_basics

   1 Rule-based Classification Engine (RBCE)
   2 -------------------------------------------
   3
   4 The ckrm/rbce directory contains the sources for two classification engines
   5 called rbce and crbce. Both are optional, built as kernel modules and share much
   6 of their codebase. Only one classification engine (CE) can be loaded at a time
   7 in CKRM.
   8
   9
  10 With RBCE, user can specify rules for how tasks are classified to a
  11 class.  Rules are specified by one or more attribute-value pairs and
  12 an associated class. The tasks that match all the attr-value pairs
  13 will get classified to the class attached with the rule.
  14
  15 The file rbce_info under /rcfs/ce directory details the functionality
  16 of different files available under the directory and also details
  17 about attributes that can are used to define rules.
  18
  19 order: When multiple rules are defined the rules are executed
  20            according to the order of a rule. Order can be specified
  21            while defining a rule.  If order is not specified, the
  22            highest order will be assigned to the rule(i.e, the new
  23            rule will be executed after all the previously defined
  24            evaluate false). So, order of rules is important as that
  25            will decide, which class a task will get assigned to. For
  26            example, if we have the two following rules: r1:
  27            uid=1004,order=10,class=/rcfs/taskclass/c1 r2:
  28            uid=1004,cmd=grep,order=20,class=/rcfs/taskclass/c2 then,
  29            the task "grep" executed by user 1004 will always be
  30            assigned to class /rcfs/taskclass/c1, as rule r1 will be
  31            executed before r2 and the task successfully matched the
  32            rule's attr-value pairs. Rule r2 will never be consulted
  33            for the command.  Note: The order in which the rules are
  34            displayed(by ls) has no correlation with the order of the
  35            rule.
  36
  37 dependency: Rules can be defined to be depend on another rule. i.e a
  38            rule can be dependent on one rule and has its own
  39            additional attr-value pairs. the dependent rule will
  40            evaluate true only if all the attr-value pairs of both
  41            rules are satisfied.  ex: r1: gid=502,class=/rcfs/taskclass
  42            r2: depend=r1,cmd=grep,class=rcfstaskclass/c1 r2 is a
  43            dependent rule that depends on r1, a task will be assigned
  44            to /rcfs/taskclass/c1 if its gid is 502 and the executable
  45            command name is "grep". If a task's gid is 502 but the
  46            command name is _not_ "grep" then it will be assigned to
  47            /rcfs/taskclass
  48
  49            Note: The order of dependent rule must be _lesser_ than the
  50            rule it depends on, so that it is evaluated _before the
  51            base rule is evaluated. Otherwise the base rule will
  52            evaluate true and the task will be assigned to the class of
  53            that rule without the dependent rule ever getting
  54            evaluated. In the example above, order of r2 must be lesser
  55            than order of r1.
  56
  57 app_tag: a task can be attached with a tag(ascii string), that becomes
  58            an attribute of that task and rules can be defined with the
  59            tag value.
  60
  61 state: states are at two levels in RBCE. The entire RBCE can be
  62            enabled or disabled which writing 1 or 0 to the file
  63            rbce_state under /rcfs/ce.  Disabling RBCE, would mean that
  64            the rules defined in RBCE will not be utilized for
  65            classifying a task to a class.  A specific rule can be
  66            enabled/disabled by changing the state of that rule. Once
  67            it is disabled, the rule will not be evaluated.