P4Info Table is missing information about its initial default action

[fruffy]

I am working on a project which consumes a P4Info message but ran into a problem with tables. For a table like this

table toggle_check {
    key = {
        h.ethernet.dst_addr : exact @name("dst_eth");
    }
    actions = {
        do_something();
    }
    default action = do_something();
}

the corresponding P4Info message will look like this:

tables {
  preamble {
    id: 40116169
    name: "toggle_check"

  }
  match_fields {
    id: 1
    name: "dst_eth"
    match_type: EXACT
  }
  action_refs {
    id: 31609776
  }
  size: 1024
}

The message loses information about the initial default action of the table. This is because the default action has not been marked const and thus the const_default_action_id field is not set. To get this information I have to look up the table in the P4 program, then identify its default action, which requires a series of convoluted steps. I can not simply rely on the P4Info file.

Maybe we could add a second field, initial_default_action_id, which specifies the initial default action of the table? At least on the compiler side, it is trivial to add and this should not break the existing API.

[smolkaj]

I assume the reason why the initial default action is not specified in the P4Info is that it is not strictly needed -- only information that is required to remote control a switch running a particular P4 program is strictly needed in the P4Info.

That said, I don't think there is a problem with adding this information despite that. We have done similar things in a few cases, e.g. for source locations, and we have been discussing adding a @format annotation that would also fall into this category.

[chrispsommers]

I agree with Steffen, Additionally, in the short term you might find what you need in the IR JSON output. I have seen cases where someone parsed that to get more info than contained in P4INFO.

[fruffy]

I agree with Steffen, Additionally, in the short term you might find what you need in the IR JSON output. I have seen cases where someone parsed that to get more info than contained in P4INFO.

I ended up writing my own compiler pass to extract this information, but I thought it might be more convenient to directly source it from the existing P4Info file.

That said, I don't think there is a problem with adding this information despite that.

What's the process for that on the P4Runtme side?

[smolkaj]

What's the process for that on the P4Runtime side?

The final decision for such questions is made in the WG meetings. Would you be able to make it to the next one to quickly present? This process is generally very easy and friendly.

In the meantime, we can discuss asynchronously on GitHub. Ideally you would prepare a PR ahead of the meeting so we have a concrete proposal, in case there are technical points that need further discussion.

[smolkaj]

It would be useful if you can say a bit more about your use case, and maybe extrapolate a bit why you think this would generally be useful.

[antoninbas]

One reason why it's not in the P4Info today (IIRC) is that this piece of information is not immutable, and is no longer accurate if / when the default action is mutated at runtime. In a way it is akin to the list of (mutable) "initial entries" of a table, which we don't include in P4Info, but for which p4c can generate a WriteRequest message in a separate file.

[chrispsommers]

Hi Antonin, that is a good point. Would having the "initial default action" in P4Info would allow a controller to understand the state of the pipeline, assuming it keeps track of all changes made to the default action? It assumes no other entity changes it. In retrospect, should/could default action itself be readable at any time?

[antoninbas]

should/could default action itself be readable at any time?

that's already the case, the controller can read it at any time using a regular P4Runtime ReadRequest

I don't feel very strongly either way. The proposed field name (initial_default_action_id) makes it clear that this is the initial state of the pipeline. But I do feel that this would be a discrepancy between how we handle the default action vs how we handle initial entries. Of course, one could argue that we already have such discrepancies in P4Info. On a related note, I pointed out a few years ago that while P4Info should indicate whether or not the default action is const, there was no real need to include the actual id of the const default action (see https://github.com/p4lang/p4runtime/issues/107#issuecomment-449202452).

I tend to agree with @smolkaj, it would be good to know more about the use case.

[fruffy]

I tend to agree with @smolkaj, it would be good to know more about the use case.

My use case is a little special, I am not sure whether it has much relevance for this particular request. But I can still describe it.

Begin digression

I am working on deriving control-plane semantics from the P4Runtime API. The semantics let me merge the basic semantic representation of a P4Program with its current active control-plane configuration. I can use this merged representation for various analysis tools, including P4Testgen.

Let's assume for the example above the default action is NoAction. The table data plane semantics, described in the form of constraints, could look like:

action_chosen_for_table_toggle_check == if (h.ethernet.dst_addr == dst_eth_key) ? do_something : NoAction 

Prose description: The action we execute for table toggle_check is do_something if we match, otherwise execute the default action NoAction. The corresponding control-plane semantics for this table in an unconfigured P4 program will look like.

action_chosen_for_table_toggle_check == NoAction

Prose description: The table has no entry and its default action is configured to be NoAction. With this constraint we force action_chosen_for_table_toggle_check to always pick the default action.

The data plane semantics always remain the same, but the control plane semantics can change with subsequent control plane updates.

The problem relevant to this particular Github issue is that I need to infer some form of initial configuration for the program. I tried to do this by using the P4Info file only, which I assume would provided enough details on the initial control plane state of a program.

But it turns out it lacked important information such as the initial default action. The omission of initial entries also causes problems. Ultimately, I ended up discarding the P4Info file and just derive all this information using my own P4 analysis pass.

End digression

I do not depend on this change any more, so I am not really blocked on this. Nonetheless thought it couldn't hurt to add information like this to the P4Info file.

What is the scope of the P4Info file exactly? My impression of the P4Info file is that it is effectively a snapshot of the active P4 program and its elements that can be accessed from the control plane. In that sense it is always immutable, no? That includes the initial default action and the initial entries, even though the active default action or entries may change over time.

My current understanding is that most P4Runtime servers maintain some internal state to track the initial entries and the default action, so it is possible to query the active default action by abusing(?) is_default_entry. However, it does not seem possible if you relied on the specification or P4Info file only. For example, this action in the P4Runtime spec I am not sure how you could accomplish using descriptions provided by P4Info only:

When resetting the default entry, its controller_metadata and metadata value as well as the configurations for its direct resources will be reset to their defaults. If the default entry is constant (as indicated by the P4 program and the P4Info message), the server must return a PERMISSION_DENIED error code if the client attempts to modify it.

[smolkaj]

Just a heads up that the next P4 API WG meeting is tomorrow.

[chrispsommers]

Notes from April 12 2024

• P4Info does not specify what initial default action is
• 1 justification: not immutable, so info from P4Info may go stale after programming. Akin to initial entries.
• Are there any negative ramifications to add this?
  • Andy: seems harmless and potentially useful
• Antonin: very similar to initial entries
  • Why aren't those in the P4Info?
  • Steffen: would like to settle this question before we make a decision, for consistency
  • Chris: could there be a security issue?
  • Once we move initial entries to P4Info, can we still allow people to put them in the binary blob instead?
  • there could be an explicit signal that they are included/excluded
  • Tentative agreement: this would be good to have!
  • Does the size of the p4info file matter?
  • Decision: would like design of both but happy to take implementation of only the default action.

[chrispsommers]

@fruffy See above, would you like to proceed with an implementation?

[fruffy]

@fruffy See above, would you like to proceed with an implementation?

I can implement the default action generation in P4C at least. https://github.com/p4lang/p4c/issues/4662