Add a scope argument to Entity message to target a subset of the HW resources

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

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.

message Entity {
  message Scope {
    repeated uint32 scope = 1;
  }
  oneof entity {
    ExternEntry extern_entry = 1;
    TableEntry table_entry = 2;
    ActionProfileMember action_profile_member = 3;
    ActionProfileGroup action_profile_group = 4;
    MeterEntry meter_entry = 5;
    DirectMeterEntry direct_meter_entry = 6;
    CounterEntry counter_entry = 7;
    DirectCounterEntry direct_counter_entry = 8;
    PacketReplicationEngineEntry packet_replication_engine_entry = 9;
    ValueSetEntry value_set_entry = 10;
    RegisterEntry register_entry = 11;
    DigestEntry digest_entry = 12;
  }
  Scope scope = 13;
}

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).

p4lang / p4runtime