[P4-design] 3rd working meeting minutes

Changhoon Kim chang at barefootnetworks.com
Mon Aug 10 02:49:55 EDT 2015

Hi P4-designers,

It seems the 24th works better for many more members. Let's meet at 4 - 6pm
on Aug/24 (Monday) at the same place.


-- Chang

On Thu, Aug 6, 2015 at 5:39 PM, Changhoon Kim <chang at barefootnetworks.com>

> 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)
> Summary:
>    - Quick summary of the last meeting (Chang)
>    - Code sample review and discussion (led by Barefoot, code samples
>    attached)
>       - Blackbox objects
>          - TLV-style header parsing (e.g., IPv4 options)
>          -  Learning support
>       - Modules
>       - Architecture definition
>    - Wishlist presentation and discussion (led by Huawei, slide deck
>    attached)
>       - 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
> egress.
> [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
> better?
> [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
> alternations)
>   - 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/20150809/27a7ce74/attachment-0001.html>

More information about the P4-design mailing list