-
Notifications
You must be signed in to change notification settings - Fork 80
LDWG meeting minutes, January 6, 2020
- Mihai Budiu (VMware)
- Calin Cascaval (Barefoot)
- Chris Dodd (Barefoot)
- Nate Foster (Cornell)
- Stefan Huele (Google)
- Vladimir Gurevich (Barefoot)
- Jed Liu (Barefoot)
- Alan Lo (Mellanox)
- Chris Sommers (Keysight)
- The proposal seeks to add
optionalas an additional match kind in the standard library.
- @stefanheule has created a PR to the Language Specification
-
The motivation is to specify a match kind that can either match exactly or not at all.
-
A meta-question is what our process is for adding things to
core.p4vs. to specific architectures. @mbudiu-vmw proposed that features common to many architectures (or where the cost of emulating or supporting is not too high) are good candidates. -
One issue is that no targets support this.
-
Another concern raised by @ChrisDodd is whether these would need priorities. @stefanheule had been thinking that there would be priorities.
-
@jnfoster asked whether there is an overarching principle for what we need to do to add a new match kind.
-
A vigorous discussion ensued about what belongs in
core.p4what what belongs in architectures. @vgurevich pointed out thatlpmwas included (whereasrangewas not) due to the high prevalence of algorithms LPM tables. -
@mbudiu-vmw observed that having an implementation would be the next step
-
@vgurevich proposed a meta-principle for adding things to
core.p4.
-
@stefanheule agreed to investigate a Bmv2 implementation for V1Model
-
@jnfoster proposed having a discussion with the P4Runtime WG
- The proposal seeks to add a new form that creates annotations with additional structure
- A existing PR has been refined based on previous LDWG discussion.
-
@ChrisDodd raised a potential concern about parsing expression lists because the comma will likely be ambiguous. @chrispsommers indicated that he was not wedded to this feature. A possible limitation is to replace
expressionListwithexpression. -
We reviewed the rationale for requiring all expressions to be compile-time known values -- i.e. to make them easy to "read off."
- @chrispsommers to review the proposal with an eye toward eliminating the parser ambiguity.
- The proposal seeks to add a set of standard annotations to allow the
compiler to optimize
externfunctions and method calls
- @jafingerhut created a series of examples as well as a PR adding the proposed annotations to PSA.
-
We discussed what kinds of annotations could be sensibly applied to an extern obejct. For example, is it possible to have a useful extern where some of the methods only manipulate local state and others also manipulate other state?
-
We discussed whether
@localIndexedState(index)needs a parameter to be useful. Seems like it... -
@jafingerhut observed that he had written down these annotations for the sake of completeness.
-
We reviewed Section 17.4.1 of language specification, which defines the concurrency model. It says that extern methods can be subject to data races, but individual invocations are atomic.
- Everyone should review the specification. This is useful in the compiler, and as documentations for humans reading P4 programs.
- We don't allow empty statements (i.e.,
;) orconditionals (i.e.,if-then-else`) in the parser.
- This issue was discovered because the compiler internally generates empty statements and conditionals, which it later eliminates.
-
@vgurevich feels this would be useful.
-
Empty statements seem like a no-brainer. Conditionals are more subjective.
-
They don't add expressive power. In fact, the compiler already eliminates them.
- @mbudiu-vmw will prototype
-
February 3rd
-
Big items: please read issues for abstract methods, module system, structure expressions, etc.!