modify_field semantics: takes effect even when src or dest parent header invalid about behavioral-model HOT 6 CLOSED

Sorry, I was sloppy with the versions of the modify_field_test and commands files; some incorrect table and action names are in the versions I supplied earlier. Here are the corrected versions:
modify_field_test.txt
commands.txt

from behavioral-model.

Hi David,
This is what I wrote on p4-dev: it is likely that a bunch of P4 capable switches won't be able to enforce these semantics for modify_field. Therefore, it is likely that the next iteration of the P4 spec will change these semantics to "undefined behavior".
Regarding bmv2, it would be in theory be possible to add an action primitive modify_field_with_check, which would only perform the assignment if a condition is valid. It could be used like this: modify_field_with_check(hA.f1, hB.f1, valid(hA) and valid(hB)). I am not sure it is worth the trouble though, as this would probably be only valid on bmv2. Note that the following is supported (and will be supported by the future spec): modify_field(hA.f1, valid(hB) ? hB.f1 : 0). It does not do what you want though.
I think the bottom line is that a "conditional write" is not something you can get right now.

from behavioral-model.

Thanks for your response. I would be the last one to argue for anything that will only be valid on bmv2, since one of the foundational points of my research is to provide a vehicle for P4 code portability across different switches.
I will adjust.

from behavioral-model.

cool, let's hope that the new version of the spec comes out soon and addresses this issue

from behavioral-model.

The proposed P4_16 spec states that this is undefined behavior (http://p4.org/wp-content/uploads/2016/12/P4_16-prerelease-Dec_16.html#sec-ops-on-hdrs): "The result of reading or writing a field in an invalid header is undefined. The result of reading an uninitialized header field is undefined — even if the header itself is valid.".
However, since bmv2 is meant first and foremost as a P4 debugging tool, we could consider having a "strict" mode that would print a warning when this happens, which is why I'm leaving this issue open for now.

from behavioral-model.

There is now an updated version 1.0.4 of the P4-14 spec published: https://p4lang.github.io/p4-spec/

It defines that if the source field of modify_field is part of an invalid header, then the read value is undefined.

Like v1.0.3 did, v1.0.4 still says that if the dest field is part of an invalid header, the modify_field operation has no effect.

There is a current discussion for exactly what is the meaning of the line that was quoted in the P4-16 spec, here: p4lang/p4-spec#285

from behavioral-model.