<div dir="ltr">Prefer Aug 17th on my end<div><br>~Leo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 7, 2015 at 8:47 AM, TOFIGH, TOM <span dir="ltr"><<a href="mailto:mt3682@att.com" target="_blank">mt3682@att.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Aug/24 works best for me<br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: P4-design [mailto:<a href="mailto:p4-design-bounces@p4.org">p4-design-bounces@p4.org</a>] On Behalf Of Anirudh Sivaraman<br>
Sent: Friday, August 07, 2015 8:22 AM<br>
To: Changhoon Kim<br>
Cc: <a href="mailto:p4-design@p4.org">p4-design@p4.org</a><br>
Subject: Re: [P4-design] 3rd working meeting minutes<br>
<br>
On Thu, Aug 6, 2015 at 5:39 PM, Changhoon Kim <<a href="mailto:chang@barefootnetworks.com">chang@barefootnetworks.com</a>> wrote:<br>
> Hi P4 designers,<br>
><br>
> Here's the meeting minutes from our last meeting (Aug/3). I've also<br>
> attached the slide deck from Huawei and the code samples from Barefoot.<br>
><br>
> Normally we'd hold our next meeting on Aug/17, but SIGCOMM is in that<br>
> week, and many of us might be traveling for that. I'd like to propose<br>
> that we meet on Aug/24 for the next meeting, and then meet again on<br>
> Aug/31 to get back onto the original schedule.<br>
><br>
> Could you please let me know which day (Aug/17 vs. Aug/24) works better?<br>
> Based on responses, I'll send out the notification as soon as possible<br>
> -- hopefully by this weekend.<br>
><br>
<br>
I am fine with either day.<br>
<br>
> -- Chang<br>
><br>
><br>
> **<br>
><br>
> Date: Aug 3rd, 2015<br>
><br>
> Time & Location: 4 - 6:15pm, Gates 104 @ Stanford University<br>
><br>
> Attendees: Tom Tofigh (at&t); Yan Luo (umass); Phani Koganti<br>
> (brocade); Haoyu Song (huawei); Raja Jayakumar (dell); Peter Newman<br>
> (cisco); Naga Katta (princeton); Mihai Budiu, Leo Alterman, Chang Kim<br>
> (barefoot); Gordon Brebner, Robert Halstead (xilinx); Anirudh<br>
> Sivaraman (MIT); Nick Mckeown (Stanford); Joe Tardo (Broadcom)<br>
><br>
> Summary:<br>
><br>
> Quick summary of the last meeting (Chang) Code sample review and<br>
> discussion (led by Barefoot, code samples attached)<br>
><br>
> Blackbox objects<br>
><br>
> TLV-style header parsing (e.g., IPv4 options)  Learning support<br>
><br>
> Modules<br>
> Architecture definition<br>
><br>
> Wishlist presentation and discussion (led by Huawei, slide deck<br>
> attached)<br>
><br>
> Per-packet-type egress control-flow specification "direct" lookup<br>
> semantics offset-and-length-based packet value extraction<br>
><br>
><br>
> Next steps:<br>
><br>
> Barefoot will come up with a draft spec capturing their latest<br>
> proposals and code samples, and share it before the next meeting. The<br>
> working team will review the draft spec together at the next meeting.<br>
> Huawei will clarify a few points regarding their proposal and present<br>
> the ideas one more time at the next meeting.<br>
> Cisco (Satyam) might propose a language-neutral API generation style<br>
> based on Yang -- depending on the schedule.<br>
><br>
> -------<br>
><br>
> More details ...<br>
><br>
> 1. Presentation and discussion led by Barefoot<br>
><br>
> [C] Continuing on the discussion from the email thread on p4-design<br>
> about language modularity and blackboxes. Some confusion stemmed<br>
> primarily from the terms being used. The term 'module' probably makes<br>
> one think of an external black-boxed building block that can be pulled in and chained.<br>
> 'object' however probably reminds one of a piece of software that is<br>
> intended to be extended and modified. Hence, the terms seem to have a<br>
> reversed meaning.<br>
><br>
> [A] Barefoot isn't attached to the terms being used. Leo thinks the<br>
> important thing is to provide a mechanism that can:<br>
>   - group together a set of P4 objects and the connections between<br>
> them (like tables, blackboxes, and control flows)<br>
>   - create multiple copies of this group, each of which represents<br>
> different "physical" instances of those objects (eg, separate objects<br>
> from the control-plane point of view)<br>
><br>
> [A] Not opposing to these ideas -- mostly just confused by the initial<br>
> proposal's terminology.<br>
><br>
> --<br>
><br>
> [C] Barefoot distinguishes between "broad" and "narrow" modularity:<br>
>   - "Broad" means a module which introduces a new networking-level<br>
> behavior (such as IPv6) by introducing new code to multiple parts of the P4 program.<br>
>   - "Narrow" means a piece of code that performs a specific task. The<br>
> module is instantiated and then called from one place like a<br>
> subroutine. Examples include a "load balancer" or "IPv4 parser that handles options".<br>
> Leo explains that the modularity in the current proposal was mostly<br>
> focused on the narrow. The proposal helps with broad modularity, but<br>
> doesn't quite address it. After quite a lot of time and thought,<br>
> Barefoot has found broad modularity a very difficult problem to tackle<br>
> and still don't know the best way to do it.<br>
><br>
> --<br>
><br>
> [Q] How will end-users decide whether to use modules or blackbox objects?<br>
><br>
> [A] End-users should NEVER write definitions of blackbox objects -<br>
> they exist solely for the compiler author or standard library to<br>
> provide to the user a palette of basic elements to compose into a<br>
> program. The core difference is that the object_type construct is for<br>
> defining functionality that is not expressible in P4, while the<br>
> module_type construct is for defining functionality that is.<br>
><br>
> [C] One draws an analogy to Lego Mindstorms, which lets users program<br>
> robots by chaining together puzzle pieces which contain various<br>
> tweakable parameters. Black-boxes are these different puzzle pieces,<br>
> their attributes are the parameters.<br>
><br>
> [C] Adding to the analogy, that modules in the current proposal would<br>
> be saving a chain of puzzle pieces as a template that could be stamped<br>
> down multiple times in different places.<br>
><br>
> [Q] Are we going to have generic 'function' support in the language?<br>
><br>
> [A] Partially because of the background with high-performance hardware<br>
> targets, I'm uneasy about introducing elements of 'general purpose<br>
> computation' into the language and doesn't know how things like<br>
> functions fit into P4.<br>
><br>
> --<br>
><br>
> [Q] What state can a module modify?<br>
><br>
> [A] Modules can only modify what is passed through their signature and<br>
> global variables. We should disallow global variables to prevent<br>
> unintended side-effects and information sharing (eg, between ingress and egress).<br>
><br>
> [Q] How could one module write a piece of state and have another<br>
> module read this state, given this restriction?<br>
><br>
> [A] The state would be defined in whatever block of code that<br>
> instantiates the reader and writer modules, and then that state be<br>
> passed down through signature parameters.<br>
><br>
> [C] Signatures might get quite long.<br>
><br>
> [A] Agreed. Structs are intended to mitigate the problem, but doesn't<br>
> believe there is any good solution to this 'signature bloat'.<br>
><br>
> [C] in' and 'out' annotations would be useful on module parameters.<br>
><br>
> [A] Agreed.<br>
><br>
> [C] A nice thing about P4 now is that you don't have to worry about<br>
> hardware-level things like not being able to share data between<br>
> ingress and egress.<br>
><br>
> [C] It's still possible to create very abstract architectures which<br>
> don't make a distinction or let you freely share state without<br>
> constraints, and it's up to a target vendor to identify whether they<br>
> can support such behavior and provide a compiler for that very abstract architecture.<br>
><br>
> --<br>
><br>
> [C] The core piece missing for parser TLV functionality is the ability<br>
> to "count down" from some number. Many headers, mostly TLV-style,<br>
> specify their length and expect the parser to exit to the next header<br>
> once that many bytes have been parsed. Currently there is no way to implement this.<br>
><br>
> [C] Barefoot proposes a blackbox that lets the parser keep such state,<br>
> and says this is enough to handle common headers like IPv4, Geneve, and TCP.<br>
><br>
> 2. Presentation and discussion led by Huawei<br>
><br>
> [Q] Is the proposal for per-packet-type egress specification mainly<br>
> for giving compiler a good hint so it can make metadata overloading<br>
> decisions better?<br>
><br>
> [A] The desire is being able to send only the useful metadata to each<br>
> egress control flow.<br>
><br>
> [C] It seems what you want is partly achieved by<br>
> architecture-languagel separation, but you would also need union types to do it properly.<br>
><br>
> [Q] Regarding the "direct" lookup semantics, the compiler could infer<br>
> direct tables from exact match tables when the key has the appropriate<br>
> size. In other words, isn't "direct" just a special case of "exact" lookup?<br>
><br>
> [A] Yes, but still being able to support "direct" explicitly might be<br>
> helpful for code writers and compilers.<br>
><br>
> [C] What's the main motivation behind lazy parsing (or<br>
> offset-and-length-based value extraction) and intermixing parsing and<br>
> packet processing?<br>
><br>
> [A] It's mostly to save cycles.<br>
><br>
> [C] It seems this could be achieved in a few ways:<br>
>   - an architecture which allows a chain of<br>
> parser/pipe/parser/pipe/parser/pipe (works for a finite number of<br>
> alternations)<br>
>   - exposing a blackbox object for this feature and allowing extract<br>
> calls in the mau pipeline, but it might be a bit hacky and potentially<br>
> very inefficient, even on software architectures (bad cache locality)<br>
><br>
><br>
> _______________________________________________<br>
> P4-design mailing list<br>
> <a href="mailto:P4-design@p4.org">P4-design@p4.org</a><br>
> Listinfo - <a href="http://mail.p4.org/mailman/listinfo/p4-design_p4.org" rel="noreferrer" target="_blank">http://mail.p4.org/mailman/listinfo/p4-design_p4.org</a><br>
><br>
><br>
<br>
_______________________________________________<br>
P4-design mailing list<br>
<a href="mailto:P4-design@p4.org">P4-design@p4.org</a><br>
Listinfo - <a href="http://mail.p4.org/mailman/listinfo/p4-design_p4.org" rel="noreferrer" target="_blank">http://mail.p4.org/mailman/listinfo/p4-design_p4.org</a><br>
<br>
<br>
_______________________________________________<br>
P4-design mailing list<br>
<a href="mailto:P4-design@p4.org">P4-design@p4.org</a><br>
Listinfo - <a href="http://mail.p4.org/mailman/listinfo/p4-design_p4.org" rel="noreferrer" target="_blank">http://mail.p4.org/mailman/listinfo/p4-design_p4.org</a><br>
<br>
</div></div></blockquote></div><br></div>