[P4-dev] Does P4 imply a specific programming model ?
chuck.ashley4 at gmail.com
Wed Oct 18 19:49:18 EDT 2017
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
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 at 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/
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-dev