[P4-design] Naming of Parts

Peter Newman (petenewm) petenewm at cisco.com
Fri Aug 7 13:43:55 EDT 2015


In explaining the meaning of the proposed “module" and “object” we used the words “template” and “component.” (We also used the word “lego brick” but I’m discounting that.) “Template” doesn’t seem any better, or less overloaded, than module but I think the word “component” does a better job at conveying what we mean than the word “object” and it is much less overloaded.

Just two cents into the pot.

—Peter


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

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

<Barefoot-p4_examples.tar.gz><Huawei-P4_changes_proposal.pdf>_______________________________________________
P4-design mailing list
P4-design at p4.org<mailto: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/20150807/60cc5093/attachment-0001.html>


More information about the P4-design mailing list