[P4-design] 3rd working meeting minutes

Changhoon Kim chang at barefootnetworks.com
Thu Aug 6 20:39:12 EDT 2015

Hi P4 designers,

Here's the meeting minutes from our last meeting (Aug/3). I've also
attached the slide deck from Huawei and the code samples from Barefoot.

Normally we'd hold our next meeting on Aug/17, but SIGCOMM is in that week,
and many of us might be traveling for that. I'd like to propose that we
meet on Aug/24 for the next meeting, and then meet again on Aug/31 to get
back onto the original schedule.

*Could you please let me know which day (Aug/17 vs. Aug/24) works
better?* Based
on responses, I'll send out the notification as soon as possible --
hopefully by this weekend.

-- Chang


Date: Aug 3rd, 2015

Time & Location: 4 - 6:15pm, Gates 104 @ Stanford University

Attendees: Tom Tofigh (at&t); Yan Luo (umass); Phani Koganti (brocade);
Haoyu Song (huawei); Raja Jayakumar (dell); Peter Newman (cisco); Naga
Katta (princeton); Mihai Budiu, Leo Alterman, Chang Kim (barefoot); Gordon
Brebner, Robert Halstead (xilinx); Anirudh Sivaraman (MIT); Nick Mckeown
(Stanford); Joe Tardo (Broadcom)


   - Quick summary of the last meeting (Chang)
   - Code sample review and discussion (led by Barefoot, code samples
      - Blackbox objects
         - TLV-style header parsing (e.g., IPv4 options)
         -  Learning support
      - Modules
      - Architecture definition
   - Wishlist presentation and discussion (led by Huawei, slide deck
      - Per-packet-type egress control-flow specification
      - "direct" lookup semantics
      - offset-and-length-based packet value extraction

Next steps:

   - Barefoot will come up with a draft spec capturing their latest
   proposals and code samples, and share it before the next meeting. The
   working team will review the draft spec together at the next meeting.
   - Huawei will clarify a few points regarding their proposal and present
   the ideas one more time at the next meeting.
   - Cisco (Satyam) might propose a language-neutral API generation style
   based on Yang -- depending on the schedule.


More details ...

*1. Presentation and discussion led by Barefoot*

[C] Continuing on the discussion from the email thread on p4-design about
language modularity and blackboxes. Some confusion stemmed primarily from
the terms being used. The term 'module' probably makes one think of an
external black-boxed building block that can be pulled in and chained.
'object' however probably reminds one of a piece of software that is
intended to be extended and modified. Hence, the terms seem to have a
reversed meaning.

[A] Barefoot isn't attached to the terms being used. Leo thinks the
important thing is to provide a mechanism that can:
  - group together a set of P4 objects and the connections between them
(like tables, blackboxes, and control flows)
  - create multiple copies of this group, each of which represents
different "physical" instances of those objects (eg, separate objects from
the control-plane point of view)

[A] Not opposing to these ideas -- mostly just confused by the initial
proposal's terminology.


[C] Barefoot distinguishes between "broad" and "narrow" modularity:
  - "Broad" means a module which introduces a new networking-level behavior
(such as IPv6) by introducing new code to multiple parts of the P4 program.
  - "Narrow" means a piece of code that performs a specific task. The
module is instantiated and then called from one place like a subroutine.
Examples include a "load balancer" or "IPv4 parser that handles options".
Leo explains that the modularity in the current proposal was mostly focused
on the narrow. The proposal helps with broad modularity, but doesn't quite
address it. After quite a lot of time and thought, Barefoot has found broad
modularity a very difficult problem to tackle and still don't know the best
way to do it.


[Q] How will end-users decide whether to use modules or blackbox objects?

[A] End-users should NEVER write definitions of blackbox objects - they
exist solely for the compiler author or standard library to provide to the
user a palette of basic elements to compose into a program. The core
difference is that the object_type construct is for defining functionality
that is not expressible in P4, while the module_type construct is for
defining functionality that is.

[C] One draws an analogy to Lego Mindstorms, which lets users program
robots by chaining together puzzle pieces which contain various tweakable
parameters. Black-boxes are these different puzzle pieces, their attributes
are the parameters.

[C] Adding to the analogy, that modules in the current proposal would be
saving a chain of puzzle pieces as a template that could be stamped down
multiple times in different places.

[Q] Are we going to have generic 'function' support in the language?

[A] Partially because of the background with high-performance hardware
targets, I'm uneasy about introducing elements of 'general purpose
computation' into the language and doesn't know how things like functions
fit into P4.


[Q] What state can a module modify?

[A] Modules can only modify what is passed through their signature and
global variables. We should disallow global variables to prevent unintended
side-effects and information sharing (eg, between ingress and egress).

[Q] How could one module write a piece of state and have another module
read this state, given this restriction?

[A] The state would be defined in whatever block of code that instantiates
the reader and writer modules, and then that state be passed down through
signature parameters.

[C] Signatures might get quite long.

[A] Agreed. Structs are intended to mitigate the problem, but doesn't
believe there is any good solution to this 'signature bloat'.

[C] in' and 'out' annotations would be useful on module parameters.

[A] Agreed.

[C] A nice thing about P4 now is that you don't have to worry about
hardware-level things like not being able to share data between ingress and

[C] It's still possible to create very abstract architectures which don't
make a distinction or let you freely share state without constraints, and
it's up to a target vendor to identify whether they can support such
behavior and provide a compiler for that very abstract architecture.


[C] The core piece missing for parser TLV functionality is the ability to
"count down" from some number. Many headers, mostly TLV-style, specify
their length and expect the parser to exit to the next header once that
many bytes have been parsed. Currently there is no way to implement this.

[C] Barefoot proposes a blackbox that lets the parser keep such state, and
says this is enough to handle common headers like IPv4, Geneve, and TCP.

*2. Presentation and discussion led by Huawei*

[Q] Is the proposal for per-packet-type egress specification mainly for
giving compiler a good hint so it can make metadata overloading decisions

[A] The desire is being able to send only the useful metadata to each
egress control flow.

[C] It seems what you want is partly achieved by architecture-languagel
separation, but you would also need union types to do it properly.

[Q] Regarding the "direct" lookup semantics, the compiler could infer
direct tables from exact match tables when the key has the appropriate
size. In other words, isn't "direct" just a special case of "exact" lookup?

[A] Yes, but still being able to support "direct" explicitly might be
helpful for code writers and compilers.

[C] What's the main motivation behind lazy parsing (or
offset-and-length-based value extraction) and intermixing parsing and
packet processing?

[A] It's mostly to save cycles.

[C] It seems this could be achieved in a few ways:
  - an architecture which allows a chain of
parser/pipe/parser/pipe/parser/pipe (works for a finite number of
  - exposing a blackbox object for this feature and allowing extract calls
in the mau pipeline, but it might be a bit hacky and potentially very
inefficient, even on software architectures (bad cache locality)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150806/cd72c391/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Barefoot-p4_examples.tar.gz
Type: application/x-gzip
Size: 3643 bytes
Desc: not available
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150806/cd72c391/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Huawei-P4_changes_proposal.pdf
Type: application/pdf
Size: 258633 bytes
Desc: not available
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150806/cd72c391/attachment.pdf>

More information about the P4-design mailing list