[P4-design] 3rd working meeting minutes

Awanish Verma awanish.verma at netronome.com
Mon Aug 10 02:56:25 EDT 2015


August 24th.


On Fri, Aug 7, 2015 at 10:31 AM, Haoyu song <haoyu.song at huawei.com> wrote:

> I prefer Aug 24th.
>
>
>
> *From:* P4-design [mailto:p4-design-bounces at p4.org] *On Behalf Of *Leo
> Alterman
> *Sent:* Friday, August 07, 2015 9:59 AM
> *To:* TOFIGH, TOM
>
> *Cc:* p4-design at p4.org
> *Subject:* Re: [P4-design] 3rd working meeting minutes
>
>
>
> Prefer Aug 17th on my end
>
>
> ~Leo
>
>
>
> On Fri, Aug 7, 2015 at 8:47 AM, TOFIGH, TOM <mt3682 at att.com> wrote:
>
>  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
>
>
> _______________________________________________
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150809/db6ccb71/attachment-0001.html>


More information about the P4-design mailing list