Where should a `@hidden` annotation on an action be placed?

[vlstill]

The spec (v1.2.4) says:

The @hidden annotation hides a controllable entity, e.g. a table, key, action, or extern, from the control plane. This effectively removes its fully-qualified name (Section 18.3). This annotation does not have a body.

and also:

Every controllable entity exposed in a P4 program must be assigned a unique, fully-qualified name, which the control plane may use to interact with that entity. The following entities are controllable.

• value sets
• tables
• keys
• actions
• extern instances

To me, it is not entirely clear where the @hidden annotation of an action is allowed, I can see two possibilities, both make some sense.

// option 1
@hidden action foo() { ... }

action bar() { ... }

table t0 {
  keys = { h.v : exact; }
  actions {
    foo;
    // option 2
    @hidden bar;
  }
}

While the first one makes more sense if we think about @hidden as a property of the name, the second option could make sense because the same action can be used in multiple tables.

What was the intention behind the spec?

---

(That said, I don't really see a motivation for hiding actions at all.)

[jonathan-dilorenzo]

I think if it removes the fully qualified name, then it only makes sense for the annotation to be on the action itself... That said, it's not totally clear to me how this would ripple to any usage. Would it not be exposed as an action in that table in the control plane either? In P4Runtime at least, that's largely not dependent on a fully-qualified name...

(Also not sure what this is for though).

[jafingerhut]

The one use case I know of off the top of my head for the @hidden annotation is to put it on a table definition. When used that way, the table is not visible to a control plane API at all, neither for adding entries, nor its key fields, nor its associated actions. One or more actions of such a hidden table might also be the non-hidden actions of a non-hidden table, in which case it makes perfect sense to me that those actions would have names visible to the controller.

I do not know of any examples where I have seen a P4 table be not-hidden, but it is defined with at least one action that is hidden. I am not sure what would be intended to happen if a controller attempted to read all entries of the table, while some of those entries used a hidden action, for example. I doubt the P4Runtime API specification has an answer to what ought to happen in this situation (but perhaps it does, and I am forgetting it). This sounds to me like a scenario where it is likely that no one wanted to do this, and no one has thought before to ask what ought to happen.

[jonathan-dilorenzo]

Mm, I think this would fall under the 'read-write' symmetry requirement basically, so no such entries should be visible. If that table was additionally marked as dataplane volatile, then I really don't know, but would probably err on the side of still 'not visible' for simplicity.

[jafingerhut]

@vlstill If you look in the directory testdata/p4_16_samples_outputs, the output of this command shows many examples of @hidden annotations on tables that are synthesized during compilation, i.e. tables that do not exist in the P4 program given to the compiler, but are created by the compiler during a front- or mid-end pass:

git clone https://github.com/p4lang/p4c
cd p4c/testdata/p4_16_samples_outputs
grep @hidden *.p4

The list of p4c passes below might not be exhaustive, but are at least a few examples of compiler passes that can add entities with the@hidden annotation (found by grep'ing for hidden in the p4c source files):

• midend/actionSynthesis.cpp
• midend/eliminateSwitch.cpp
• frontends/p4/simplifyDefUse.h