Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharpen the notion of read-write symmetry #407

Open
smolkaj opened this issue Dec 9, 2022 · 4 comments
Open

Sharpen the notion of read-write symmetry #407

smolkaj opened this issue Dec 9, 2022 · 4 comments

Comments

@smolkaj
Copy link
Member

smolkaj commented Dec 9, 2022

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.

image

@smolkaj
Copy link
Member Author

smolkaj commented Dec 9, 2022

@smolkaj
Copy link
Member Author

smolkaj commented Dec 9, 2022

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?

@jfingerh
Copy link

jfingerh commented Dec 9, 2022

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

@jafingerhut
Copy link
Contributor

@smolkaj Note that data plane volatile tables are NOT unique to NICs. See some notes in this issue: #408

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants