[P4-dev] Does P4 imply a specific programming model ?
vladimir.gurevich at barefootnetworks.com
Thu Oct 19 01:59:48 EDT 2017
I am not sure I am qualified to answer such a broad question. It sounds
like you are thinking about the time where there will be networks, where
each node is executing a certain data plane program written in P4 (that's
the only way I can interpret your words "P4 programmable network").
First of all, as much as I am personally excited about P4, I think that it
will be quite a while before such networks appear and even then it is not
clear to me whether *all* the devices in them will use data plane
algorithms written in P4, similarly how in the "ordinary" world of
computers people use a variety of programming languages to write programs.
P4 is really good for describing high-speed processing, but if you want to
have loops, recursive functions and things like that, P4 is probably not
the right choice to begin with.
However, this is probably not important in the context of your question,
where you are wondering about "P4-programmable control plane". I am not
sure I've seen this term before (especially since P4 is a language for
programming data plane (and not control plane) algorithms), but I'd assume
that you are really asking about the interface between a control plane and
a data plane program written in P4.
Well, the good news is that P4 has the ability to describe both the data
plane algorithm (the program) and the control plane interface for it. P4
Runtime is the most current effort to codify that situation, although other
methods, such a program-dependent APIs exist too. What is interesting, at
least in my view, is that once P4 Runtime grows into a universal interface,
capable of expressing the control plane interface for any P4 program (which
I believe is, indeed, the goal), then it will also be quite suitable to
express interfaces between the control plane and data plane programs
written in other languages as well!
The reason I make this statement is because the interface between the
control plane and data plane programs is, strictly speaking, independent
from the language either one is written in. Again, to invoke familiar
analogy, when you use a certain interface to interact with a certain
program, the language that program has been written in is usually the least
of your concerns, meaning that it should be possible to have the same
framework applied to a wide variety of devices, probably much wider than
just the ones programmed in P4. If true, it will be a big deal.
Another thing I want to point out is that from the network perspective, the
control plane/data plane interface matters only if the network is using
centralized control. If the network uses distributed control, where each
node has its own control plane, then the interface between the data and the
control plane will probably stay hidden inside the node. But, if he network
uses more centralized control, then having a common framework, such as P4
Runtime, would be extremely beneficial. It would be similar to having an
army, where each soldier understands only a certain set of commands, but
they all speak the same language and such an army is much easier to control
compared to one where each set of soldiers speak their own language.
To summarize, the control plane interfaces, currently developed for P4
programs (and specifically P4 Runtime framework) once done should be able
to cover all devices running P4 programs, no matter how different they
might be and, ideally, the same framework can be used on even wider variety
of the devices.
In terms of your second question, I think that the presentation I gave at
the P4 Developers' Day (P4D2) in May 2017 (https://www.youtube.com/
watch?v=DptVDfxjoSk) might provide some useful insights on how this mapping
is achieved in practice. P4 was certainly created with RMT as the major
inspiration and it runs on RMT devices (like Barefoot Tofino) quite well to
say the least.
On Wed, Oct 18, 2017 at 4:49 PM, Chuck Ashley <chuck.ashley4 at gmail.com>
> Thanks Vladimir for your prompt reply,
> The context of my questions is trying to determine how P4 programmable
> network model will look like,
> Assume some future network deployment with a mix of NICs & switches/FPGAs,
> all capable of supporting P4 programming. How do you vision the
> P4-programmable control plane to look like, given that switches/FPGAs
> utilize a pipeline architecture in stages split, whereas the NICs use an
> architecture that is more analogous to a general purpose CPU architecture
> in run-to-completion feature split?
> I mean, is it realistic to expect to develop a common end to end P4 based
> programming model or each of these components/architectures to be handled
> My 2nd question is how technically pipeline processing on switches/FPGAs
> is represented in P4; I realize that P4 is a target-independent language
> with no concept of stages per se; is there an expectation from a
> vendor-specific backend to resolve direct acyclic graph representation of
> flows, delivering programmable switch architectures such as RMT
> (Reconfigurable Match-Action Tables)?
> Also just to confirm, any performance/target-specific hardware constrains
> reside out of scope of P4.org work and are expected to be resolved by
> vendor-specific backend tools, right?
> Thanks in advance, Chuck
> On Sun, Oct 15, 2017 at 9:43 PM, Vladimir Gurevich <vladimir.gurevich@
> barefootnetworks.com> wrote:
>> Hell Chuck,
>> Welcome to P4. Please, find (most of) the answers inline.
>> On Sun, Oct 15, 2017 at 8:55 PM, Chuck Ashley <chuck.ashley4 at gmail.com>
>>> I am new to this group and very excited about P4 ideas and the change it
>>> may drive to hardware.
>>> I have a question about the programming model assumptions P4 makes, if
>>> Does P4 assume/dictate any specific target device architecture?
>> If by the word "architecture" you mean the same thing as P4_16 spec (a
>> set of P4-programmable and non-programmable components that form a specific
>> platofrm as well as their interfaces), then starting with P4_16 it
>> officially does not dictate any specific architecture, but even P4_14 is
>> flexible enough to accommodate different architectures.
>> As a shameless plug I'd recommend you to take a look at the P4_16 video
>> tutorial <https://www.youtube.com/watch?v=GslseT4hY1w> and pay specific
>> attention starting at about mark 28:24
>>> Is there a "standard" P4 library structure that P4 implies / provides as
>>> a public reference implementation (not only for software simulators but
>>> also for real hardware targets)?
>> I am not sure what you mean by the "standard P4 library structure", but
>> if you mean "architecture", then there are a couple, although HW target
>> support is not yet complete:
>> - The so-called "V1 Model", discussed in the presentation. This is a
>> simple architecture that was intended to provide an easy transition from
>> P4_14 with all its legacy naming and such. It supports only simple programs
>> - The Portable Switch Architecture (PSA) that is intended to be a
>> fully functional and portable P4_16 architecture for switches. It is
>> currently going through standardization process and you can see it for
>> yourself on Github at https://github.com/p4lang/p
>> Are P4 programs written in feature split or in pipeline stage split?
>> In my view, feature split is analogous to a run to completion model that
>>> is probably suitable to run on NICs NPUs, while per-stage split is
>>> analogous to a traditional pipeline programming model and probably matches
>>> how P4 will describe high capacity switches that are pipelined because that
>>> is how they are architected.
>>> While the feature programming model for switches may be novel, it also
>>> may be very brittle when applied to pipeline architecture and limit how
>>> creative customers can become.
>> Suffice it to say that P4 is designed to be target-independent language
>> and has no concept of stages per se.
>> At the same time it is difficult for me to comment on your assertions
>> about something being "brittle" or "limiting" without knowing exactly what
>> you mean. P4 was, indeed, designed to allow efficient implementation on
>> modern high-speed pipelines. One of the specific consequences is the
>> absence of the loops in the control flow functions and that was a
>> deliberate choice, but any flow that can be represented as a direct acyclic
>> graph is expressible.
>> So far, the main limit to creativity I've observed was the reluctance to
>> sit down and write a program, but this is not an exclusive property of P4 :)
>> Happy hacking,
>> *Vladimir Gurevich*
>> *Barefoot Networks*
>> *Technical Lead, Customer Engineering*
>> Email: vag at barefootnetworks.com
>> Phone: (408) 833-4505
*Technical Lead, Customer Engineering*
Email: vag at barefootnetworks.com
Phone: (408) 833-4505
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-dev