LDWG meeting minutes, February 4, 2019

Attendees

Mihai presented slides summarizing the issue.
Fundamental problem: need a way to preserve metadata data for { recirculate, resubmit, clone } operations.
The way v1model.p4 is designed, it cannot implement these operations.
- recirculate(a) and b = a; recirculate(b) are equivalent
- Also recirculate is evaluated eagerly.
PSA solution
- Emit recirculated data in deparser and extract in parser.
- Explicit and low-level and not clear what happens if there are multiple paths to recirculate.
Three solutions:
- Explicit input/outputs
- Annotations on metadata
- Use pair of functions
Explicit input/outputs: like PSA
Annotations
- Add @recirculate annotation on fields that should be recirculated
- Or maybe add @recirculate(1), @recirculate(2), etc. for different field lists.
Special "channel" functions

extern RecirculateChannel<T> {
  T recirculate_receive();
  void recirculate(in T data);
}

Do we have a serious proposal for P4_14-like field lists?
Extern has the advantage of not cluttering up the data-plane interface
Needs two additional features:
- List expressions as l-values.
- A way to disambiguate multiple channels.
- How to test between multiple channels in a parser?
Action Item: Sleep on it, comment on the p4c PR.
Note that we regressed. Could we run as a part of Travis?

The PR modifies the language specification to allow arbitrary free-form annotations.
The older text about key-value pairs for the reserved @pkginfo annotation has now been relegated to a subsection.
- Chris asked if we should move this text to the P4Runtime Specification?
- Others felt it was worth keeping in the main P4 Language Specification
This change has led to an issue with the annotations in the TypeMap maintained by the compiler. It now needs to be cleared. @liujed will look into this.
There's a small issue in the parser -- adding small syntax extensions for annotations currently requires copying the expression production.
Aside: should we add a range expression? Actually, they already exist for keysetExpressions.
Action Item: @liujed to make some further changes, then we'll merge.

This was previously discussed.
Action Item: Everyone should take a look, then we might be ready to merge this.

We added a new issue on the language specification focused on generalizing l-values to handle lists.
There's a tricky issue when the same sub-expression occurs multiple times in the same top-level l-value.

If there is activity by February 20th, we'll have another meeting on February 25th.