[P4-design] P4 language evolution
Gordon.Brebner at xilinx.com
Mon Jun 15 18:26:51 EDT 2015
Further comments on just one of my original topics: MATs and actions.
From: P4-design [mailto:p4-design-bounces at p4.org] On Behalf Of Mihai Budiu
Sent: Wednesday, June 10, 2015 12:06 PM
To: p4-design at p4.org
Subject: Re: [P4-design] P4 language evolution
I am replying to a previous email from Gordon Brebner, which didn't make it to the mailing list.
[GB] I realize of course that Match-Action tables are the lifeblood of OpenFlow etc. and hence P4, but would like at least to discuss whether tables should directly contain static actions, or whether they might contain something like pointers or selectors that are then interpreted by action execution units. On the abstraction side, this allows a bit more generality through dynamic behavior; on the implementation side, this reflects that real tables just return bit strings.
[MB] The P4 v1.x spec has something called "action profile" which was designed for this purpose, but I hope it's not necessary as a special construct; we should be able to model all its functionality by using two tables where the actions in the first table "compute" an index in the second table. We should analyze your use case to see whether it can be handled or not in this way. If something can be expressed as a combination of the existing primitives, but implemented in a special way under the covers without requiring heroic compiler effort, then it hopefully does not need special language support.
Agreed that it would be nice to simplify out the "action profile" declarations. Mihai's suggestion would indeed enable a switch-like feature using the second MAT as a switch. (The use of action profiles as shorthand for repeated action sequences might presumably be addressed elsewhere, in the syntactic sugar department.)
Thinking about what I originally meant a bit more, I realized that I had in mind conditional behavior in general, not just switch-style selection. As things stand, there are two main vehicles for conditional behavior:
1. The match-action tables themselves: restricted to AND-with-masking conditions, with constants populated at run time;
2. The control flow sequences: where generic if-condition-else statements can be used, with expressions populated at configuration time.
So these come across as two separate pieces of the language, and I wondered whether they could be made more harmonious. Or is the essential linguistic point that it's highlighting two separate types of conditions, one run time (and hence more restricted), the other configuration time?
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-design