antoninbas
commented
3 years ago @pudelkoM thanks for submitting this, we discussed the changes at the P4 API WG meeting today (10/23/2020). I think the takeways are:
- there seems to be consensus that adding the
scopefield to theEntitymessage is useful (based on current use cases on Stratum) and low-risk - things are not as straightforward for the
ForwardingPipelineConfigmessage change:- for devices like Tofino, physical pipes cannot be configured independently: it has to be done at the same time (in other terms, changing the forwarding config for one pipe cannot be done without affecting the config of other pipes); to accommodate this restriction, the
ForwardingPipelineConfigmessage could be changed to support multiple "configurations" - before even trying to address the above bullet point however, we need to look into which use cases we want to support and decide if we want 1) a global P4Info message which includes object definitions across all logical pipelines, or 2) one P4Info message per logical pipeline definition. Terms have yet to be defined, but a logical pipeline definition can be mapped to multiple physical pipelines, which means that these physical pipelines implement the same P4 logic (same set of P4 objects), and can be programmed (table entries) symmetrically or asymmetrically. It seems that at the moment, 1) covers the known Stratum use case. However, with 1), it is not possible without knowing how to interpret the target-specific device config (
p4_device_config) to determine whether a write operation on anEntityis valid based on the P4 object id & thescopevalue. 2) could support compiling P4 programs from 2 different stakeholders independently and then using them for different pipelines (they can share the same id space).
- for devices like Tofino, physical pipes cannot be configured independently: it has to be done at the same time (in other terms, changing the forwarding config for one pipe cannot be done without affecting the config of other pipes); to accommodate this restriction, the
I believe we can start with adding a scope field to the Entity message, without any other change. However, we still need to update the specification accordingly to 1) define the appropriate terminology, 2) present some multi-pipe device model that users can refer to, 3) based on the device mode, describe which use cases we are trying to support and which are out-of-scope.
@bocon13 @ccascone @saynb - hopefully this is not to inaccurate based on our discussions, please feel free to commen
chrispsommers
bocon13
TODOs:
Fixes #316