[P4-design] P4 language evolution
mbudiu at barefootnetworks.com
Wed Jun 10 15:06:05 EDT 2015
I am replying to a previous email from Gordon Brebner, which didn¹t make it
to the mailing list. The message is quoted in entirety below in red.
I apologize for problems with the mailing list; they are due to the fact
that we migrated the P4 website from godaddy but not the mailing list, and
now the mailman at godaddy is misconfigured. Unfortunately godaddy cannot
support a custom configuration. We are still looking into a permanent
solution. In general, URLs for managing the mailing list should start with
mail.p4.org instead of just p4.org.
Replies to Gordon¹s email are inline.
Thanks for putting this document together. I recognize most of the points
from your earlier powerpoint slides that we discussed last time we met, and
I generally support the analysis and proposed directions. I think it is
exactly right to take stock now based on early experience, and contemplate
fairly radical changes before anything gets too set in stone.
I have a few top-level comments/discussion points for now. I did sign up to
the new mailing list, but my request doesn¹t seem to have been approved yet,
hence email just to this set of contributors.
Some remarks, following through the order of things in the document:
· 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.
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.
· It¹s understandable why P4 is not to be Turing-complete. But
perhaps a positive statement might be that it is ³Right-moving
Turing²-complete not a term I¹ve ever seen before, but we are essentially
talking about a right-moving TM (= no left moves) here, I think.
· I wasn¹t sure that (seventh bullet) that P4 being restricted to
describing how packets are forwarded would be perceived by many as a ³good
feature². It might suggest that it addresses an over-restricted domain. I
wonder if it is possible to precisely differentiate ³fast path packet
processing² as a sub-domain from ³universal packet processing², then one
could clarify why this restriction is explicitly good, rather than just
being a fact.
The boundary between "universal" and ³fast² is fuzzy. I expect the language
will slowly evolve to become more universal. I assume that evolution won¹t
be a problem if it does not sacrifice the ability to compile the fast
subset of the language to run very efficiently (multi Tbps).
· The minor shortcoming relating to simple control flow constructs
(fourth bullet) is undoubtedly related to the capability of targets for
doing complex control flow, so this requires a delicate balance to get right
on both sides.
The intent of the ³P4 conformance² definition is exactly to leave room for
such ³restricted subset of P4² implementations.
· The minor shortcoming concerning excessive concurrency (sixth
bullet) makes a point, but I¹d incline towards ³minimalsequentiality² where
possible to avoid being restrictive. I think humans can cope with some
level of concurrency (especially when one doesn¹t explicit mention that
things are concurrent, so they don¹t even perceive there to be an issue).
The problem highlighted in the document is that you CANNOT express
non-concurrent behavior with the current spec, even if you want to. If it is
necessary, I don¹t think it would be an abuse of the language to eventually
extend P4 to have something like a ³parallel block² construct for explicit
· Given the various other proposals being made in terms of changing
models, I think it would be good to discuss at least the existence of
deparsing. As mentioned under shortcomings (eighth bullet, fifth
sub-bullet), currently it¹s restricted to assuming the same outgoing packet
format as was incoming, so the natural question is whether there should be a
parse plus edit (= update packet) model rather than the current
decompose-recompose model. The key underlying question is: how much
relationship is there between what is input and what is output, which gets
more interesting when going beyond a simple 1:1 packet-in/packet-out model.
The goal is to provide a language to express packet reassembly when needed,
but not to enforce all targets to support it. In fact, one may have a switch
model in which there is no deparser. To support your proposal requires
defining a ³complete" set of packet editing operations. My hope is that all
these can be actually folded into library definitions, and thus can be added
without changing the P4 language. And I believe that the same model could
support 1:many packet operations as well at least for a constant value of
³many². Broadcast probably needs some more serious thought.
· The desire for a strongly-typed language (third bullet) is
completely understood. However, some practical experience I¹ve had is that
one has to be careful not to be excessively strong, given that real packet
handling can sometimes involves playing fast and loose with the fact that
everything is a bit string at the end of the day, and that it might be
useful to interpret this in different ways in different places. I¹m not
saying it¹s not possible to be strongly-typed, just that it mustn¹t hinder
The biggest discussion topic, I think, is around the decoupling of P4 from a
switch architecture. I utterly agree that this is a good move, which
immediately broadens the scope of P4 application. However, as framed in the
document, the new model seems to be just that there will be a range of fixed
packet-processing engines, containing P4-programmable holes. As you know
because I¹m already doing such things via our PX language another level of
potential programmability is the programmatic description of these
architectures: like how many and what kinds of holes, and how they¹re
connected together. And there is a relationship between the kinds of data
flow through such programmed architecture graphs, and (assuming it¹s staying
in P4) the control flow piece showing how control passes through tables.
So, although this area might be seen as outside the scope of the current P4
thrust, I think it is something that should be considered in tandem. (I say
this from my experience where, in our previous generation, we had separate
languages for programming holes and for describing the surrounding context,
and I then thought it better to put both in the same language this time.)
I agree that having a model language would be very useful. The trouble is
that I have no idea yet how this language would look. In this proposal we
discussing incremental changes to P4, but a model language would be a truly
major change. Based on your own paper for modeling Click, it looks like the
model language would be significantly more complex than P4 in its entirety!
This suggests that a more extensive review process would be needed to define
the model language.
Note that when I say that the model language is a ³separate language² this
does not preclude this being under the P4 umbrella. In some sense the
³parsing², ³match-action² and ³deparsing² languages are all ³separate²
languages, with different capabilities (e.g., you cannot write
state-machines in the match-action part), but they are all unified in the
scope of P4. I am sure P4 has room for additional extensions.
Anyway, just some preliminary comments for now. I¹m very much looking
forward to the workshop on Thursday next week.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-design