Some architectures like the Tofino Native Architecture (TNA) for the Barefoot Tofino chip consist of multiple parallel hardware pipelines, instead of the usual one. They are attached to distinct sets of front panel ports, can be individually programmed and have independent state. Currently there is no mechanism in P4Runtime to target such a subset of the pipelines.
Examples
Asymmetric table entries
In some cases table entries only apply to a subset of ports (e.g. setting VLAN id based on egress port), but all rules still are inserted into all pipelines. By selectively inserting there entries in only the relevant subset, resources can be used more efficiently.
Registers & counters
Since the pipelines share no state, the registers and counters in them are not in sync. While this can be mitigated for counters (totaling them up), this does not make sense for general purpose registers (e.g. calculating flow hashes).
Proposed changes
Adding an optional scope message to the Entity allows targeting on both the read and write path. The absence of a Scope message specifies the current behavior. If set on entities that do not allow or support scopes (e.g. PRE on Tofino), the server return an INVALID_ARGUMENT error.
Should the scope also apply to the ForwardingPipelineConfig message to allow programming individual pipelines?
How should the scope be specified? Is an array of integers enough for all types of entities (e.g. parser value sets)?
P4Info has a Scope enum, should we chose a different name?
Alternatives
Externs provide a way to extend the P4RT protocol unilaterally for a platform/architecture/vendor. Since the details are then defined by the specific implementation, interoperability between SwitchOSs and control planes might be lower than with a standardized solution.
Treating each pipe as a separate device with its own device id provides an even higher level of isolation.
Assuming the user only wants to program a small part of the tables / entities asymmetrically, this could result in extra overhead for the controller (maintaining the StreamChannel, ensuring all common entries are inserted).
Problem
Some architectures like the Tofino Native Architecture (TNA) for the Barefoot Tofino chip consist of multiple parallel hardware pipelines, instead of the usual one. They are attached to distinct sets of front panel ports, can be individually programmed and have independent state. Currently there is no mechanism in P4Runtime to target such a subset of the pipelines.
Examples
Proposed changes
Adding an optional scope message to the
Entity
allows targeting on both the read and write path. The absence of a Scope message specifies the current behavior. If set on entities that do not allow or support scopes (e.g. PRE on Tofino), the server return an INVALID_ARGUMENT error.Open Questions
Should the scope also apply to the
ForwardingPipelineConfig
message to allow programming individual pipelines?How should the scope be specified? Is an array of integers enough for all types of entities (e.g. parser value sets)?
P4Info has a Scope enum, should we chose a different name?
Alternatives
Externs provide a way to extend the P4RT protocol unilaterally for a platform/architecture/vendor. Since the details are then defined by the specific implementation, interoperability between SwitchOSs and control planes might be lower than with a standardized solution.
Treating each pipe as a separate device with its own device id provides an even higher level of isolation. Assuming the user only wants to program a small part of the tables / entities asymmetrically, this could result in extra overhead for the controller (maintaining the StreamChannel, ensuring all common entries are inserted).