Define a term "data plane volatile" in P4Runtime specification

jafingerhut commented 1 year ago

This proposal arose in a P4.org API work group discussion on 2022-Dec-09 about read-write symmetry.

The following types of objects are known to be able to change their state by data plane actions alone, without any action being taken by a controller:

counters can be updated
P4 registers can be written
P4 tables with PNA's new add_on_miss = true table property can have new table entries added by data plane initiated actions
P4 tables with PNA's new pna_idle_timeout = PNA_IdleTimout_t.AUTO_DELETE; table property can have existing table entries removed by the data plane, if they exceed their configured idle time.
P4 tables with the previous new property, OR the existing value of NOTIFY_CONTROL, can have the idle timeout value configured for an entry changed by the data plane on its own.

Note: add-on-miss and auto-delete-on-idle-timeout are NOT exclusive to NICs. There are many switch ASICs that can do this, too, often because of Ethernet MAC address learning of source MAC addresses, but other features like Netflow/sFlow, and others.

It would be good to define a term that covers this category of objects that break read-write symmetry because they are data plane volatile, and perhaps introduce a new P4Info property that indicates whether a particular P4 object is data plane volatile or not. While it is true that ALL counters and P4 registers are data plane volatile, there can be P4 programs where some P4 tables are data plane volatile, while others are not, and it would be nice to be able to distinguish which P4 tables are which from P4Info file contents.

smolkaj commented 1 year ago

+1. @verios-google @jonathan-dilorenzo for visibility. Linking https://github.com/p4lang/p4runtime/issues/407, which is about strengthening read-write symmetry.

jafingerhut commented 1 year ago

Some notes while thinking about what to say in the spec about data plane volatility. I may propose a PR based on this soon. Correction/comments/questions all welcome.

Read/write symmetry really only matters for things that can be written by the controller.

TODO: Are all such things ones that can appear in a WriteRequest message? Or are there others?

Within a WriteRequest, there can be 0 or more Update messages. Each Update message can contain one Entity:

message Entity {
  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;
  }
}

Which of these are data plane volatile?

ExternEntry

Volatility depends upon the extern.

TableEntry

For a table with a direct counter associated with it, the counter_data field of a TableEntry can be modified by the data plane when packets match the entry.

For a table with a direct meter associated with it, the meter_counter_data field of a TableEntry can be modified by the data plane when packets match the entry.

For a table with any of these property values:

psa_idle_timeout equal to PSA_IdleTimeout_t.NOTIFY_CONTROL, as defined in PSA.
pna_idle_timeout equal to PNA_IdleTimeout_t.NOTIFY_CONTROL or PNA_IdleTimeout_t.AUTO_DELETE, as defined in PNA.

the data plane can modify the elapsed_ns field of a TabeEntry when packets DO NOT match the entry for an implementation-specific amount of time.

Similarly, for a table in PNA with any of the values of pna_idle_timeout listed above, the data plane can modify the idle_timeout_ns field of a TableEntry when packets match the entry and the action calls the set_expire_time extern function.

For a table with the property add_on_miss equal to true, as defined in the PNA, the data plane can add new entries to the table without the controller's involvement.

For a table with the property pna_idle_timeout equal to PNA_IdleTimeout_t.AUTO_DELETE, as defined in PNA, the data plane can delete existing entries from the table without the controller's involvement.

ActionProfileMember

Not data plane volatile in any existing architectures.

ActionProfileGroup

Not data plane volatile in any existing architectures. The watch_port feature does affect how action selectors behave while processing packets, but this feature does not affect what a P4Runtime client sees when it reads the configuration.

MeterEntry

The field counter_data is modified by the data plane when the corresponding meter is updated in the data plane.

DirectMeterEntry

The field counter_data is modified by the data plane when the corresponding meter is updated in the data plane.

CounterEntry

The field data is modified by the data plane when the corresponding meter is updated in the data plane.

DirectCounterEntry

The field data is modified by the data plane when the corresponding meter is updated in the data plane.

PacketReplicationEngineEntry

Not data plane volatile in any existing architectures.

ValueSetEntry

Not data plane volatile in any existing architectures.

RegisterEntry

The field data can be modified by the data plane when the corresponding register entry is updated in the data plane.

DigestEntry

Not data plane volatile in any existing architectures.

jafingerhut commented 1 year ago

See this PR: https://github.com/p4lang/p4runtime/pull/412

p4lang / p4runtime