[P4-design] 3rd working meeting minutes

TOFIGH, TOM mt3682 at att.com
Fri Aug 7 11:47:28 EDT 2015


 Aug/24 works best for me

-----Original Message-----
From: P4-design [mailto:p4-design-bounces at p4.org] On Behalf Of Anirudh Sivaraman
Sent: Friday, August 07, 2015 8:22 AM
To: Changhoon Kim
Cc: p4-design at p4.org
Subject: Re: [P4-design] 3rd working meeting minutes

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
>
>

_______________________________________________
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