Abstract methods access outer variables in Tofino

[MollyDream]

The Tofino architecture is inconsistent with the spec. The spec states that “The abstract methods can only use the supplied arguments or refer to values that are in the top-level scope”, but in the Tofino architecture it needs to allow developers to access outside variables in the registerAction’s apply method. Specifically, it seems that users should be able to update a register value with some variables, and since there is no such in argument in apply and execute, they need to access variables like hdr.ipv4.ipaddress directly.
Two possible ways to fix this: the P4 spec needs to be relaxed to allow reading values outside the scope and not in top level; the tofino.p4 needs to be updated to include the variables users want to read as in arguments.

[jnfoster]

This is a known inconsistency between the spec and the implementation. Thanks for flagging it.

[mihaibudiu]

This is a problem that has been known for at least 6 years; the design committee just recently accepted abstract methods without captured variables; we have to do some more work to add this capability in the official language.

[QinshiWang]

This is a problem that has been known for at least 6 years; the design committee just recently accepted abstract methods without captured variables; we have to do some more work to add this capability in the official language.

In what you would suggest, abstract methods may capture variables but only for reading. Is that correct?

[mihaibudiu]

Unfortunately in practice people need them to also capture variables for writing.
To enable this capability without completely breaking the compiler we need to inform the compiler about when these abstract methods could be invoked. If an abstract method can be invoked at any time, then it cannot capture variables either for reading or for writing, since it would race the main program.
However, we contemplate adding some annotations @synchronous and @asynchronous; the @asyncnronous annotation describes a function that could be invoked anytime by the environment. a @synchronous(callers) annotation is followed by a list of other methods which can invoke the said abstract method as part of their execution. The compiler needs to be able to limit when the callers are invoked, and thus understand that such a call may cause the side-effects incurred by the abstract method.
We still have to discuss this in the design group. We have made some strides in this direction, e.g. #802, but we are yet to discuss this in full.

[QinshiWang]

@mbudiu-vmw Could you tell me what synchronous and asynchronous state means, when mentioned here #802 (comment)?

[mihaibudiu]

That is a complicated topic. I don't even remember whether I attempted to write it down at some point, as I said, it's been open for at least 6 years. And, as many complicated topics are, it may be that once you try to write down the rules you realize that you don't really understand the problem well (see our prior attempt to formalize pure functions, which split them into many different categories). I don't think a comment box for an issue is the right place to discuss this.
We should be discussing this in some LDWG meetings; prior to that it would be good to write down something, though.
If you can help with this effort we would be very grateful, and I am very happy to discuss this in a side channel.
(Perhaps our newly announced office hours?)

[jnfoster]

In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.