-
Notifications
You must be signed in to change notification settings - Fork 78
LDWG meeting minutes, February 3, 2020
- Antonin Bas (VMware)
- Mihai Budiu (VMware)
- Chris Dodd (Barefoot)
- Andy Fingerhut (Cisco)
- Nate Foster (Cornell)
- Stefan Heule (Google)
- Eileen Feng (Google)
- Jed Liu (Barefoot)
- Steffen Smolka (Google)
- Chris Sommers (Keysight)
- Konstantin Weitz (Google)
-
We need to make faster progress on closing issues.
-
Mihai has added new columns to the issue Wiki for target version and status.
-
P4 Summit coming up on April 28th-30th, which is our target for a new version (v1.3).
-
We discussed major (v1.3) vs. minor (v1.2.1) releases.
-
Would like to use various types in controller programs that are mapped to P4 types (e.g., logical names and switch's physical ids).
-
P4 has a
typeconstruct that allows the programmer to generate a new type (e.g.,type bit<9> port;). -
Here is an example
type bits<8> port_id;
port_id port;
table t {
key { port : exact; }
...
}
This doesn't currently work, but it could, since equality is defined
on generative types. However, if exact were ternary it shouldn't
be allowed (because masking is not supported).
-
In real applications, it would also be useful allow
optionas a match-kind. Even with generativetypes there is no issue with doing this. -
Going a step further, it would also be useful to support sets. Note that a standard encoding of sets using bit-masks doesn't work since generative
types are opaque (e.g.,bit<128> ports = 1 << port_id).
- https://github.com/p4lang/p4-spec/issues/794
- https://github.com/p4lang/p4-spec/issues/795
- https://github.com/p4lang/p4-spec/issues/799
* @konne-google will continue to prototype implementations of these new match kinds in V1model
* @jafingerhut will work on summarizing what types can be used as keys to tables at a given match kind.
- We added
@pureandnoSideEffectsannotations (and others) to allow the compiler to (partially) analyze the behavior of externs.
- The two main annotations,
@pureand@noSideEffectsare already useful in the compiler. We don't have a usecase for the other variants.
-
@ChrisDodd will split the PR
-
We aim to merge the simple annotations at our March meeting.
- The proposal seeks to allow
if-then-elsestatements in parsers.
-
The main pass is already implemented, but some work is needed to fully integrate into the compiler.
-
In the past, pushback has been about making the cost of a parser harder to analyze from the program text.
-
Indeed, each top-level conditional requires three extra states.
-
@mbudiu-vmw will take on implementation work
-
We aim to merge this proposal at our March meeting.
--
- Work on fuzzing the compiler out of NYU found a bug related to associativity of
>>.
-
@ChrisDodd will look into fixing the specification.
-
We aim to merge this proposal at our March meeting.
-
@hesingh has added support for run-time indexing to header stacks.
-
The specification does not say what should happen for assigning to an out-of-range index. The proposal is to tighten this up, perhaps by defining it to be a no-op.
- Making this consistent with headers seems sensible.
-
@jafingerhut will work on specification wording.
-
Note that using a non-compile-time-known-values as an index is already an optional feature.
- We've discussed several inter-related features: default initializers, structure-valued expressions.
-
@jnfoster will take the lead on pushing this to consensus.
-
We wil aim to have a proposal ready to be approved by the March meeting.
- We reviewed the existing proposal and subsequent discussion on GitHub.
- Per our convention, we'll meet at the "regular time" and "regular date" on the first Monday in March -- i.e., March 2nd at 11am PST.