-
Notifications
You must be signed in to change notification settings - Fork 80
LDWG Brainstorming, June 22, 2020
A recording of the meeting is available.
This was a special out-of-band meeting dedicated to exploring interesting avenues for the future development of the language. The meeting was attended by Zoom by 29 participants. There were 4 short presentations followed by discussions each.
- Stefan Heule --- Google "P4 Language - Ideas for Future Directions"
He described how P4 is being used at Google for specifying the behavior of switches (even non-programmable switches), for simulation and testing, and for specifying control-plane APIs via P4Runtime.
The specification of control-plane features today in P4 is awkward and requires many annotations, e.g., formatting, unique consistent id allocation, naming. Ideally these should be part of the language itself.
The semantics of the various table match kinds is not described in any document; some of these should be specified.
Also, the table initializers do not support filling up tables with user-defined match kinds.
- Tom Herbert --- Intel "Beyond Packet Processing towards Protocol Processing"
This presentation was geared towards understanding what can be done to make P4 more suitable for host networking (as opposed to the current usage, which is mostly tailored for switches). The current landscape of programming host endpoints was surveyed, and was found inadequate. Moreover, P4 does not provide support for many features needed for end-hosts. The packet parsing language from P4 was found to be a good tool to write parsers for end hosts (e.g., protocol dissectors).
- Stephen Ibanez --- Stanford "P4 Architectures and Data Plane Events"
This presentation was about using P4 to specify event-based processing, rather than packet processing. This is based on a paper at HotNets https://dl.acm.org/doi/abs/10.1145/3365609.3365848. Events should be a first-class citizen in P4 (e.g., queue overflow, timers, link status changes, control plane triggers).
Another desirable aspect of P4 would be to more completely specify the behavior of architectures, and perhaps even some of the architectural blocks that are not necessarily programmable, similar to how Verilog can be used to specify the interconnection of modules when programming an FPGA.
- Vladimir Gurevich --- Barefoot Academy "Some Ideas for P4_16"
P4 as a programming language does not support code reuse. Adding a new header requires changing code in many places. This problem is known in programming languages as the "expression problem": https://en.wikipedia.org/wiki/Expression_problem. Although it's a hard problem, we can probably alleviate the difficulties to some degree if not totally solve them.
P4 also does not describe at all the Control-plane APIs, including control-plane APIs that have no relation to the data-plane (e.g., reset all values in a register). We should have a language to describe such APIs.
The language does not support versioning. Naming entities is awkward. Finally, actions should allow struct arguments; this would help with modularity as well.