[P4-design] 3rd working meeting minutes

Anirudh Sivaraman anirudh at csail.mit.edu
Fri Aug 7 11:21:35 EDT 2015


On Thu, Aug 6, 2015 at 5:39 PM, Changhoon Kim
<chang at barefootnetworks.com> wrote:
> 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.
>

I am fine with either day.

> -- 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)
>
>
> _______________________________________________
> P4-design mailing list
> P4-design at p4.org
> Listinfo - http://mail.p4.org/mailman/listinfo/p4-design_p4.org
>
>




More information about the P4-design mailing list