-
Notifications
You must be signed in to change notification settings - Fork 82
PSA meeting minutes: Jun 26, 2017
Notes courtesy of Andy Fingerhut and Han Wang.
- On Stanford campus: Calin Cascaval (Barefoot, co-chair of PSA group), Andy Fingerhut (Cisco), Nate Foster (Cornell, visiting Barefoot), Heidi Ou (AliBaba), Han Wang (Barefoot), Vladimir Gurevich (Barefoot)
- Remote: Dan Daly (Intel, co-chair of PSA group), Andy Keep (Cisco), Skip Booth (Cisco), James Coole (Cisco), John Marshall (Cisco), Samar Abdi (Google), Bapi Vinnakota (Netronome)
Dan Daly presented some slides for overall goals of PSA working group.
Goals: Composability, Portability, Comparability
Not clear whether we will achieve all of these goals in the first attempt.
These are high level goals for P4 programs in general, but it is often easy to write non-portable P4 programs. Hopefully the PSA will help make these goals easier to achieve.
Calin: Non-goal is performance portability.
Question: Is a reference implementation planned?
Calin: The plan is that bmv2 in p4lang/behavioral-model will be a reference implementation.
Skip Booth: Would bmv2 be extended to be able to have a single-stepping debugger? This is just one example of many possible features that could be added.
Calin: I think PSA should be a good example of how to add a new architecture to bmv2 and p4c open source tools, both an implementation and hopefully also documentation on how to do it.
This group is the "P4 Architecture working group", which is not restricted to only the PSA.
In scope for discussion: PSA could be defined as "include these standard externs that are meant to be shared across multiple architectures", plus perhaps some PSA-specific objects. Another alternative is for PSA to not have pieces that are intended to be reused in other architectures.
Calin: I think that is in scope.
Andy: Some aspects of PSA, like counters, meters, and registers, seem like they could relatively easily be defined in such a way that architectures other than PSA could reuse them.
Dan: To summarize, we will document what we come up with, but also a software reference implementation of it in p4lang/p4c and p4lang/behavioral-model.
Calin: We have attempted to invite people from a variety of backgrounds, e.g. AliBaba, VMware, Google, Intel, Cisco, Barefoot. Please speak up for things that you want from your organization.
Andy: What is overlap with control plane API working group?
Calin: We are not defining the control plane API in this group, but we should take a shot at specifying at least informally what the control plane APIs are for counters, meters, registers, etc.
Skip: It might be more challenging to specify control plane APIs for PRE, BQE, etc. e.g. do we specify APIs for creating queues? deleting queues?
Dan: Shouldn't we call this "control plane API" something else? That seems like a confusing name to call it.
Someone (I did not recognize their voice)(Bapi?): Is there any interest in parameterizing an architecture? Perhaps in terms of clock rate?
This person was asking for some way to estimate performance of a program without having to compile it and measure its performance. That seems difficult, given the variety of implementations we expect to be created.
Andy: P4 benchmark projects like Whippersnapper seem like a better focus for comparing performance across implementations: http://p4benchmark.org
Calin: I think it is in scope to define what it means to call extern methods concurrently from different packets, but that is not what you are asking.
Vladimir: Would like PSA to be an architecture that is possible to write a translator that automatically converts P4_14 programs to P4_16+PSA programs, and they have the same behavior.
Not in scope, v1model program to PSA program translator.
Question: Should PSA allow black-box implementation if cannot achieve consensus on extern’s behavior? Not clear at this time that we need to go that route. The black-box implementation can be a derived architecture.
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 email list
- Github issues on p4lang/p4-spec, for which people will be assigned issues they will drive to completion.
Please send out soon any functionality you see completely missing from the proposed PSA list of externs/metadata. For example, these kinds of things:
- Should parser value sets be included (P4_14)
- Readable time
- Link state readable
- Queue lengths
From Heidi:
- QoS - what kinds of features?
- monitoring
Skip: I haven't thought through carefully the truncate / recirculate / resubmit / PRE / multicast parts of the current draft PSA. How should we proceed on those, and who has thought them through so far?
Calin: I wrote down the initial implementations. Please file a Github issue if you have concerns on particular parts of this.
Calin: Think of the applications we want to support via PSA, and see whether the proposed draft PSA includes all of the features you would want.
Examples: INT, L4 load balancing.