Define unidirectional vs. bidirectional tables in spec

[jafingerhut]

Define unidirectional vs. bidirectional tables in spec

[jnfoster]

Just to note: given mutable state (e.g., registers, or even a header stack) and any form of recirculation, it probably won't be decidable whether a table is bidirectional or unidirectional.

[jafingerhut]

If this is more subtle than I am imagining, it is probably best to talk about this in person rather than over Github issues, but all I am thinking of here is that in a single execution of a P4 control, it should be possible to symbolically and statically determine from the source code of that control a logical condition under which a table is applied if it is true, and not applied if it is false.

I realize that not all formulas are this simple, but a straightforward example is:

if ((stdmeta.direction == PNA_Direction_t.NET_TO_HOST) && (meta.foo == 5)) {
    t1.apply();
}

This is clearly a unidirectional table, since the condition implies that the stdmeta.direction must be NET_TO_HOST.

There are other such logical formulas where it definitely does NOT imply that stdmeta.direction is always one value, or always the other (e.g. the condition (hdr.ipv4.dstAddr > 50), at least in the absence of knowledge of any relationship between that input field and the direction of the packet). If there truly are undecidable cases, then I'd say that a compiler should call it a bidirectional table in the absence of straightforward provable evidence that it is unidirectional.

[hesingh]

Why use annotation? Use a new table property to specify if a table is used for incoming or outgoing or both direction. For Network Packet Broker, only hardware is used with a symmetric hash which matches both directions.