-
Notifications
You must be signed in to change notification settings - Fork 80
PSA Meeting Minutes Jan 31, 2018
Calin Cascaval edited this page Feb 1, 2018
·
1 revision
- Samar, Tom, Vladimir, Han, Calin
- online: AndyF, AndyK, James, Joe Tardo, BapiV, Venkat Pullela
- Parser Value Sets - https://github.com/p4lang/p4-spec/issues/565
- discussion on what we can do for release and not prevent change later
- CPU port semantics – https://github.com/p4lang/p4-spec/issues/321
- Add Register constructor with initial value: https://github.com/p4lang/p4-spec/issues/461
- Packet ordering recommendation - https://github.com/p4lang/p4-spec/pull/552
- Atomicity of control plane operations - https://github.com/p4lang/p4-spec/pull/554
- Digest extern updates - https://github.com/p4lang/p4-spec/pull/558
- PortId_t translation - https://github.com/p4lang/p4-spec/pull/562
- Congestion-based drop mechanisms - https://github.com/p4lang/p4-spec/issues/497
- Effect of multiple pipelines on Register extern - https://github.com/p4lang/p4-spec/pull/564
Postponed to later releases:
- Timestamps verbiage for INT: https://github.com/p4lang/p4-spec/issues/510
- Virtual functions for action_selector: https://github.com/p4lang/p4-spec/issues/446 (waiting for LDWG)
- New extern for down-selecting from a set of large keys: https://github.com/p4lang/p4-spec/issues/516 (need examples)
- Idle timeout https://github.com/p4lang/p4-spec/issues/523
- Examples of packet paths: https://github.com/p4lang/p4-spec/issues/476
- mental model: table with match key the values in the set, actions that set the next state
- static vs. dynamic entries
- tables have typically dynamic entries
- in parser, most entries are static entries. Exception is the dynamic entries that are in the value set
- parser sub-language is not sufficient to express dynamic entries
- first proposal with an extern is the most clear code
- externs do not have semantics in the language
- so using the extern as a label is outside the language
- will require changing the language
- is_member does not require language changes -- the only virtue
- group votes that this is a kludge
- Tom: proposes to have the select as a control plane entity that is addressable
- AI: Han to bring the proposal to the language WG
- AI: Andy move the PVS to rip it out and mention open issues
- AI: Han to tag the feature as experimental, but keep in the compiler
- sending to CPU is identical to sending to any other port and any metadata needs to be added in explicit headers
- AI: Andy to clarify in the text
- do we require initialization or not?
- what happens to packets that are not initialized?
- AI: Calin to merge the PR
- PR available
- AI: people agree that this is a reasonable recommendation. Andy to merge the PR.
- PR available
- requirements not recommendations. control plane implementations rely on these operations being atomic.
- implementation of Ranges -- do we accept piece-wise atomic behavior for Range?
- AI: Andy to add exception to ranges in the text. Implementations can add annotations to side-step atomicity. Andy to add to PR explicit note that if a PSA implementation supports doing an apply operation on the same table multiple times per packet (there is no requirement that this be supported, though), then one or more control plane updates may occur on the table between those apply operations. It is individual control plane updates that are atomic relative to individual apply calls.
- Andy gave overview of changes, which include notes on digest message relative ordering from data plane to control plane. No requirements there on PSA implementations, more warnings to control plane authors on there being no ordering guarantees here.
- Han: Should Digest pack calls be restricted to IngressParser and EgressDeparser control blocks only?
- AI: Andy to update PR to propose that PSA implementations only need to support Digest instances and pack calls in IngressParser and EgressParser.
- Andy gave overview of the additions and their motivation
- No issues raised during discussion.
- It proposes specific numerical bit widths intended to be large enough to hold values of types like PortId_t, MulticastGroup_t, ClassOfService_t, etc. across all PSA implementations. Everyone interested please review those numbers to see if they look too small, or much wider than necessary.
- AI: Samar to review and provide comments after meeting
- Samar to create proposed addition of 1 ‘congestion experienced’ bit filled in by PRE.
- No expectation that this be in PSA spec 1.0.