Sharpen the notion of read-write symmetry
smolkaj opened this issue · comments
As discussed in today's WG meeting, the definition of read-write symmetry in the spec is currently fuzzy, and the spec makes no gurantees ("reads and writes [...] should be symmetrical and unambiguous"). Opening this bug to track the effort to improve this.
With #406, we are planning to require servers to use canonical encodings in all responses. At that point, we should be able to strengthen the gurantees around read-write symmetry, i.e. by strictly requesting the server to guarantee the property.
However, as discussed in the meeting, we must exclude certain fields/messages from read-write symmetry, as they can be modified by the dataplane; for example, counter, registers, and perhaps certain tables in the NIC space. In the WG meeting, we discussed introducing a notion of "dataplane-volatile" entities for that purpose, and explicitly exempting dataplane-volatile entities from the read-write symmetry requirement.
@jafingerhut @antoninbas @jonathan-dilorenzo @verios-google @kishanps for visibility.
To me, there is also a question about (i) read-only entities and (ii) writable entities that were never written. One possibility would be to exempt both from read-write symmetry, by having the guarantee we provide take the form of an implication, as follows:
If a client wrote w to entity e, and there were no subsequent writes to entity e, and e is not dataplane-volatile, then readying back e should yield back value w.
This would allow the switch to come up in an arbitrary initial state. My sense is this is something we want to allow?
I am pretty sure that most P4 implementations (in the absence of const entries or the new entries proposal) will initially load a P4 program in a state where all P4 tables contain 0 entries. There might be other exceptions to that, e.g. special SetForwardingPipelineConfig options that explicitly request that table entries from an earlier loaded P4 program should be preserved if possible (I do not know the detailed specification requirements/shoulds in this case off the top of my head).
Maybe said differently, I think the initial state is not currently arbitrary, but it isn't necessarily spelled out by the read-write symmetry requirement, but other requirements elsewhere (some of which might not be written down explicitly in a P4.org specification yet, but could be).
