To what extent do we check equivalence of table actions?

[jaehyun1ee]

P4 tables may specify the default_action property where Section 14.2.1.3. Default action of the official spec states:

If present, the default_action property must appear after the action property. It may be declared as const, indicating that it cannot be changed dynamically by the control-plane. The default action must be one of the actions that appear in the actions list.

The unclear part here is, how we should check the last part, The default action must be one of the actions that appear in the actions list. "one of the actions" is unclear, of whether it means syntactic equivalence or semantic equivalence. Examples are:

action a() {}
control c() {
    table t {
        actions = { .a; }
        default_action = a; /* semantically, a is the same as .a here, but not syntactically */
    }
    apply {}
}

control c()
{
  bit<2> tt;
  action a(in bit v1, in bit v2) { tt = v1++v2; }
  action a1(in s v) { tt = v.f0++v.f1; }
  table t
  {
    actions = { a1({ f0 = ext0(), f1 = ext1()}); }
    default_action = a1({ f1 = ext1(), f0 = ext0()}); /* also, semantically the same arguments, but not syntactically */
  }
  apply {}
}

For the latter case, it may be problematic if ext0() and ext1() is side-effecting, as the order of which they are called affects the program semantics.

It is probably too onerous to precisely state what the same is in the spec, but at least there is an unclear part in the current spec we might want to discuss further.

Below are related tests in the p4c test suite:

• p4c/testdata/p4_16_samples/issue2037.p4
• p4c/testdata/p4_16_samples/issue3671.p4

[jafingerhut]

I am not sure what p4c implements today, but as you point out, it definitely accepts the two examples you have linked.

If we ignore parameters for a moment, I think the answer is probably pretty straightforward -- the names of the actions must be the same, after resolving them both to full hierarchical names. That is why a and .a are the same in one of your examples above.

When parameters are given, agreed that things seem to get potentially a lot more subtle. It seems to me that attempting to define in the spec, and implement in p4c, some omniscient idea of what is semantically equal is a never-ending can of worms. e.g. What if two extern functions with different names are invoked, but semantically they behave the same way?

It appears that p4c today does implement some kinds of semantic equivalence, e.g. the order of initializing fields in a struct is ignored. Even that seems to be entering the "can of worms" territory if you think carefully about it -- in the example above, what if extern functions ext0() and ext1() called in that order behave one way, but called in the opposite order behave a different way? Each can cause side effects on state within the implementation that affects the behavior of the other one.

[ChrisDodd]

I'm not entirely sure what the non-directionless arguments to actions are supposed to support in general, or how they are supposed to be implemented. While the p4c frontend supports them, I'm not sure which (if any) backends do.

[jafingerhut]

I have seen vgurevich propose an example use like this (from memory, and not checking compilability right now):

bit<2> meter_result;

action do_color_meter_update(in bit<2> packet_incoming_color, bit<16> meter_idx) {
    mycolorawaremeter1.execute_meter_color_aware(meter_idx, packet_incoming_color, meter_result);
    // possibly other statements here
}

table t1 {
    // whatever key fields you want here
    actions = {
        do_green_packet_metering ::= do_color_meter_update(MeterColor_t.GREEN);
        do_yellow_packet_metering ::= do_color_meter_update(MeterColor_t.YELLOW);
        do_red_packet_metering ::= do_color_meter_update(MeterColor_t.RED);
        // perhaps other actions here
    }
    default_action = do_green_packet_metering;
}

That example uses a not-implemented syntax proposed by vgurevich to locally rename actions in the actions list, of the form "<new_action_name> ::= ...". (I am not advocating adding that to the language spec by writing this comment -- I bring it up only to give an example of directionless args to actions that could be useful to invoke from a table).

I am pretty sure that the above is equivalent to the following, which requires no changes to the language spec that I know of:

bit<2> meter_result;

action do_color_meter_update(in bit<2> packet_incoming_color, bit<16> meter_idx) {
    mycolorawaremeter1.execute_meter_color_aware(meter_idx, packet_incoming_color, meter_result);
    // possibly other statements here
}

action do_green_packet_metering(bit<16> meter_idx) {
    do_color_meter_update(MeterColor_t.GREEN, meter_idx);
}

action do_yellow_packet_metering(bit<16> meter_idx) {
    do_color_meter_update(MeterColor_t.YELLOW, meter_idx);
}

action do_green_packet_metering(bit<16> meter_idx) {
    do_color_meter_update(MeterColor_t.GREEN, meter_idx);
}

table t1 {
    // whatever key fields you want here
    actions = {
        do_green_packet_metering;
        do_yellow_packet_metering;
        do_red_packet_metering;
        // perhaps other actions here
    }
    default_action = do_green_packet_metering;
}

As far as I can think of at this moment, if the language ONLY supported actions in a table's actions list that had only directionless arguments (or no arguments at all), one could always use a technique like my last example above to effectively invoke actions that did have direction-ful arguments.

[shyukahn]

Section 14.2.1.3. Default action of the official spec states this about the arguments of a default action:

In particular, the expressions passed as in, out, or inout parameters must be syntactically identical to the expressions used in one of the elements of the actions list.

Therefore, the spec requires syntactic equivalence of the arguments, not allowing the second example. It seems that P4C's implementation could be considered as a relaxation, or may be an error.

[jonathan-dilorenzo]

Discussed in April P4 LDWG.
Decisions:

• Names should resolve to the same fully qualified form
• Parameters must be accepted when syntactically identical, but may be accepted when semantically the same

Next steps:

• Create PR clarifying spec.
• Mark the test as not being required to be supported by a spec compliant compiler.