-
Notifications
You must be signed in to change notification settings - Fork 82
PSA meeting minutes: Jul 10, 2017
Notes courtesy of Andy Fingerhut.
- On Stanford campus: Calin Cascaval (Barefoot), Nate Foster (Cornell/Barefoot), Han Wang (Barefoot), Vladimir Gurevich (Barefoot)
- Remote: Andy Fingerhut (Cisco), Andy Keep (Cisco), Samar Abdi (Google), Heidi Ou (AliBaba), Tom Tofigh (AT&T), Bapi Vinnakota (Netronome).
- Parser value sets #339
- Counting #308, #312
- Reject semantics #339
- Write-only methods #316
- Index out of bounds for counters, meters, and registers #323
- Unspecified forwarding op behavior #317
- Packet arrival time #336
- and more generally handling of timestamps
- Multiple classes of service exposed in PRE #334
- Queue lengths #335
- and more generally exposing internal structures
- Meter and register initial state #324
- Meters: GREEN or RED?
- Registers: 0
- target specific
#337 - Parser value sets (https://github.com/p4lang/p4-spec/issues/337)
AI Andy Fingerhut: Write a proposed pull request, including a proposed control plane API that allows any of these possibilities: single exact match entries, ternary value/mask, range [min, max]. Ideally the control plane API should look as much like the P4 table API as possible (without actions or action parameters), add members.
Nate Foster: These value sets seem like they are a significant subset of a P4 table's functionality. Instead of this value set extern proposed on this issue, would we want to allow a P4 table that has no action to be apply()'d from a parser state, and allow the parser to use the 'hit' boolean value?
Some more discussion on whether adding ValueSet extern or allow restricted 'action-less' P4 tables in the parser. It would require a change to the P4_16 v1.0.0 language spec, since table apply() calls are explicitly not allowed in that version of the spec.
Tofigh: We have a use case that I am wondering whether having a table available in the parser would be helpful or not.
We will want the control plane API working group to review any proposed control plane APIs in the PSA spec.
TODO: Add place-holder issue for p4-spec for next P4 language design work group, considering whether to allow 'action-less' P4 tables to be invoked from the parser. The 'entrance ticket' proposed for this feature would be some actual working program(s) that would be improved if the proposed feature were added to the P4 language.
Q: do we need to expose implementation, e.g., TCAM?
Q: Even if we program the control plane with a table abstraction, do we want to push the table abstraction into the data plane?
#308 - Count operations https://github.com/p4lang/p4-spec/issues/308
Proposal:
Restrict direct counters to be packet counts only, i.e. every update always adds 1. Byte counters would not be supported.
Regular counters: count bytes, platform_bytes (platform specific)
Also remove the counter type from the constructor of the direct counters, since they would always be packet counters.
Nate Foster: How do we support direct counters in the control plane, in terms of indices? Probably best left to the control plane API working group?
Vladimir Gurevich: I think the way to think about direct resources (e.g. direct counters and direct meters) is that there is extra state added to each P4 table entry.
It sounds like from later discussion (I don't know who said it), that how direct counters and meters are addressed/indexed are the same as how the corresponding P4 table entries are addressed/indexed.
AI Nate Foster to update the PSA text in this regard.
AI Vladimir Gurevich - Think about whether direct counters and meters will be updated automatically when a table is apply()'d, or whether the actions of that table must call a method to cause an update to occur, and without those, no counter update will occur.
AI Vladimir Gurevich - Write example P4_16 program, or a portion of one, demonstrating how direct counters/meters are associated to a particular table.
AI Andy Fingerhut - Write draft PRs
- PacketLength_t - not used anywhere in the document
- entry_key -- not a single type for the architecture, but rather it is a reflection of the table.
- Q: are the control plane API captured by P4 runtime.
- A: PSA should specify that the counters/meters will use the P4 runtime mode of addressing
Reject semantics (https://github.com/p4lang/p4-spec/issues/339)
Some discussion on the 2 alternatives on this issue.
Bapi V: had a vote for the 'minimal' processing, meaning option #1, but with a mandatory counter update when a packet reaches a reject state in the parser.
Vladimir pointed out that option #2 might be better in some cases, because there are ways that a parser can reach an error state for reasons that are not under program control, but depend upon the packets arriving, e.g. header stack depth exceeded, packet too short, etc.
Vladimir also mentioned that we can have a global action that can be called in the parser to drop the packet (drop_on_parser).
initial draft of PSA document - 2017-Jul-31 PSA v1.0 - 2017-Sep-30
bmv2 support - 2017-Jul-31 p4c support - 2017-Aug-30
- p4-arch@lists.p4.org email list
- Github issues on p4lang/p4-spec, for which people will be assigned issues they will drive to completion.