Document what to do about type `bit<0>` values in several situations

[jafingerhut]

This issue should be closed exactly when the bullet item “Added support for 0-width bitstrings and varbits” in Section 1.1 "P4 Language Version Applicability" is addressed and removed.

This issue is a spinoff of issue https://github.com/p4lang/p4runtime/issues/389 that focuses on only one new feature in Version 1.2.2 of the P4_16 language spec, the one that allows values with type bit<0> to be defined. Open source p4c allows values with that type to be included as fields in structs, headers, be keys of tables, and be parameters of actions, and probably other uses as well.

As of 2023-May-06 latest version of p4c:

If you use a field with type bit<0> as a key field in a table, the P4Info file has a match_fields sub-message for the tables message for that table, with no bitwidth field inside, probably because it has value 0 and thus is not printed when showing the text format of the proto message. I did not try to send a P4Runtime table add to such a table to see what happened.

Questions:

• Should we say it is unsupported to have such a key field with type bit<0>? I cannot think of any practical benefit to allowing it.
• If we do support it, what should its behavior be?

If you use a field with type bit<0> as a directionless action parameter, the P4Info file has params sub-message of the actions message for that action with no bitwidth field, again probably because it has value 0 and is thus not shown in the protobuf message. I did not try to add a table entry with such an action to see what happened.

Questions:

• Should we say it is unsupported to have such an action parameter with type bit<0>? I cannot think of any practical benefit to allowing it.
• If we do support it, what should its behavior be?

[jafingerhut]

Here is a small P4 program and the P4Info file output by a recent version of the open source p4 compiler to examine, related to this issue: https://github.com/jafingerhut/p4-guide/tree/master/p4runtime/issues/p4runtime-issue-428

[chrispsommers]

@jafingerhut re: your two questions, I'd be curious what the answers are for the p4-16 language itself, i.e. why is it allowed and what is the use?

[jafingerhut]

I have never used a type bit<0> in a P4 program before, myself. I haven't seen it used by others, either (but I don't necessarily review mountains of P4 code -- hill-size things, perhaps). I have not run across a problem yet where using a value of type bit<0> seemed to be the answer.

I have created this issue on the p4-spec repo to see if anyone responds: https://github.com/p4lang/p4-spec/issues/1252

[chrispsommers]

I'll try to summarize the conclusions so far:

• bit<0> action param is not necessarily useful and would unlikely to be coded explicitly as bit<0>. It's more likely to be the result of evaluating something like bit<#PROFILE_BIT_WIDTH> and 0 is a corner-case (https://github.com/p4lang/p4-spec/issues/1252#issuecomment-1547004133)
• P4info generated for this "correct" if a bit mysterious because the bit width of zero results in a missing or default entry, e.g. see example

  match_fields {
  id: 3
  name: "h.h.b0b"
  match_type: EXACT
  }

To repeat the questions posed by Andy:

Should we say it is unsupported to have such an action parameter with type bit<0>? I cannot think of any practical benefit to allowing it. If we do support it, what should its behavior be?

My vote: Assuming a message can actually be constructed with a zero-width action param:

• Allow it (simply to avoid making a special case to disallow it either on client and server side), but state that it has no consequence. This hopefully lets validation and handler code be totally generic, but it should respond gracefully in such cases. Add a bit of clarifying language to the P4RT spec.

If there is something inherently problematic about formatting such a message, we should reconsider.

[jafingerhut]

I have not tried it yet, but if someone wants to create a small P4 program with at least one action having a bit<0> parameter, and at least one table with a key field with type bit<0>, and try via open source P4Runtime API to add, modify, and delete entries that have these things in them, and it all works in reasonable ways, then simply documenting those behaviors in the P4Runtime API spec with a sentence or three seems good to me. I haven't done those experiments yet.

[chrispsommers]

@jafingerhut This might be a good example of "micro-projects" which folks in the P4 community might enjoy helping on. I wonder if there is a way to crowdsource such things?

[jafingerhut]

@smolkaj As discussed in the 2023-Jul-14 meeting, a table with a single key with type bit<0> is a good test program to try out to see if (a) P4Runtime API implementation today allows you to add an entry to such a table, or experiences some kind of error, and (b) if it does support adding such an entry, does a packet sent in that causes that table to be apply'd get a hit or a miss?

[smolkaj]

Thanks Andy for documenting this here -- I agree these are good first things to check.

@kheradmandg FYI, these questions could be relevant to you in the context of VLAN modeling.