search

p4lang / p4runtime

Specification documents for the P4Runtime control-plane API
Apache License 2.0
142 stars 88 forks source link

Consider adding pagination style APIs to P4Runtime #360

Open jafingerhut opened 3 years ago

jafingerhut commented 3 years ago

Currently the P4Runtime API supports reading one, all, or a selected subset of entries of a table, and there are requirements in the spec that when reading multiple or all entries of a table, the key-action pairs must represent a consistent snapshot of the table's contents at some point in time.

(Aside: Hopefully such consistent snapshot guarantees are not currently present in the spec for counter or register array values, since that can be a pretty tricky thing to implement for values that can change per-packet processed in the data plane -- I have not checked the current spec to see if it says anything about this, but might be good to call it out explicitly as not guaranteed to be a consistent snapshot of the data plane state.)

When reading all entries of a very large table (e.g. 1 million or more entries), this can lead to operations in the P4Runtime server that require taking a significant amount of time, blocking all other requests that might modify its results, and/or allocating significant chunks of memory to store the consistent snapshot while letting other modification operations proceed, or fancier implementation techniques. On the P4Runtime API transport connection between server and client, the entire message must be contiguous and the client must consume it completely before it can receive any other messages (perhaps I'm wrong on this and gRPC enables notification messages to somehow be transported without waiting for a previous long message to be transmitted?)

Some switch ASIC driver software supports pagination APIs, e.g. one request reads the first 10,000 entries, and a later second explicit request from the client requests the next 10,000 entries, etc. until all entries have been read. There are also many databases and microservice APIs that support similar types of APIs when the result size of some query can be very large.

I do not have a specific proposal for P4Runtime API message formats yet, nor even what the consistency guarantees should be, other than to suggest that if pagination APIs exist, it seems expensive to guarantee that all such entries returned represent a consistent snapshot of the table's contents at one point in time.

@bocon13 Pinging you on the creation of this issue, since you sounded interested in thinking about this topic and perhaps proposing something more specific.

jfingerh commented 1 year ago

@jameschoi I will ping you on several public p4runtime issues to call your attention to them. For others, sorry for the comment noise.