Minor fix-ups to support for tables with initial entries and their P4Runtime API output files

[jafingerhut]

I approved of PR https://github.com/p4lang/p4c/pull/3748 because I think it is a good significant start at a full implementation of tables with entries without const before entries, and I preferred having something that is nearly complete merged in sooner, and make minor additions or fixes to it later, because I do not know how long it will take for the P4 API work group to finalize their decisions on those details.

See https://github.com/p4lang/p4runtime/issues/426 for the issue on the P4Runtime API specification. When that issue is resolved, this one should be revisited.

The minor issues that I know of that remain are:

• it seems likely that we will want some per-table property in the P4Info file for tables that have entries but not const entries, and this seems likely to be some new field, not is_const_table. When a name and semantics for that new field have been decided, it should be written to the P4Info file for such tables by p4c.

• How should entries marked const inside of entries be distinguished from those NOT marked const, inside of the "entries" output file?

• How should priorities be written to the entries output file for tables with largest_priority_wins = false? Since the entries file is always consumed by P4Runtime API, I would recommend that the priority values calculated for entries from the source code by p4c should become (M-P) in the P4Runtime entries file, where P is the priority of the entry calculated by p4c, and M is some maximum supported priority value by P4Runtime API, perhaps 2^32 or (2^32-1).

[jafingerhut]

Also create a PTF test that verifies:

For a table with const entries:

• that the table entries are all initially there and can match packets
• that server rejects with proper error code any attempt to delete or modify an entry.
• that server rejects with proper error code any attempt to add an entry to the table.
• that reading the entries returns new const flag equal to true on all entries.

For a table with const default_action

• reading the default action returns new const flag equal to true on the default action

For a table with entries without const before entries:

• that the table entries are all initially there and can match packets
• that server rejects with proper error code any attempt to delete or modify an entry with a const qualifier on the individual entry that we are attempting to modify or delete.
• that server allows adding a new entry to the table (under the size limit)
• that server allows modifying or deleting an entry that does not have const qualifier on the entry in the source code.

[jafingerhut]

PR https://github.com/p4lang/p4c/pull/4080 has been merged now, which is significant progress on completing this issue.

What remains to be done:

• implementing the P4Runtime API server changes in BMv2 v1model via some combination of changes to p4lang/PI and/or the p4lang/behavioral-model repositories. I am not planning to do this, nor do I know of anyone in Intel planning to do so. To my knowledge, Intel does not use BMv2 for anything internally.
• Implementing this in P4-DPDK P4Runtime API server, which is a process called infrap4d that can be build from open source here: https://github.com/ipdk-io/ipdk. This is open source, so anyone can do this, but if no one else volunteers, it seems likely to be developed by someone at Intel at some point in the future. I don't have any ETA to offer at this time.
• Developing automated tests as suggested in earlier comments above to verify that these implementations are working as specified.