Document JSON field base_default_next

[jafingerhut]

The current docs/JSON_format.md document does not mention field base_default_next. It would be good to mention something about it, including any cases where we know that its presence or absence actually affects how BMv2 behaves for such a program.

Motivated by this comment, and also see the follow up comments for more details: https://github.com/p4lang/behavioral-model/pull/1287/files#r1913623565

[jafingerhut]

This requires more double-checking to see whether it is actually true, but perhaps this statement is true:

• base_default_next is only used by BMv2 for tables that have no default_entry key.

Today, a JSON table produced by p4c bmv2 back end has no default_entry key if the P4 source code has an implementation of action_profile or action_selector.

However, if we implement this enhancement to p4c: p4lang/p4c#5101 then those tables will also have default_entry.

Today, there might be P4_14 source code that the p4c bmv2 back end will have no default_entry key. I have not confirmed this, but it seems somewhat likely.

Background: The P4_16 language spec has defined since version 1.2.2 (released May 2021 [1]) that if a P4 table does not explicitly specify a default_action property, the table behaves as if it had default_action = NoAction();. This is why most P4_16 tables (i.e. the ones that do not have action_profile or action_selector) always have a default_entry key in the JSON file.

[1] See https://p4.org/wp-content/uploads/2024/10/P4-16-spec-v1.2.5.html#sec-summary-of-changes-made-in-version-122-released-may-17-2021, the bullet item mentioning NoAction, and in the section that bullet item links to, search for NoAction.

[jafingerhut]

I have today learned the following by compiling this p4c test program: https://github.com/p4lang/p4c/blob/main/testdata/p4_16_samples/action_profile-bmv2.p4

and running a simple PTF test that sends a packet through, that always misses on both tables, because no entries, profiles, or groups have been added to either of the tables.

As of 2025-Jan-17, and since 2016, the p4c bmv2 backend has given a warning when attempting to compile P4_16 v1model architecture programs with a default_action property, and an implementation property that is action_profile or action_selector, saying that default_action is not supported by the target. (That was enhanced in BMv2 in 2018, but the p4c bmv2 backend seems not to have been updated to take advantage of that support yet.)

This results in those 2 tables in the JSON have no default_entry key. When BMv2 gets a miss on such a table, it executes no action (note: it does not execute an action named NoAction -- it executes no action at all.). The next table to execute is in this case determined by the value of base_default_next defined in the JSON for that table.

I'd be happy to forever eliminate support for tables that have no default_entry key, and thus also remove base_default_next, but I understand if others would prefer keeping backwards compatibility for tables without default_entry for some number of years to come.