[P4-design] Naming of Parts

Gordon Brebner Gordon.Brebner at xilinx.com
Fri Aug 7 17:18:12 EDT 2015

I've already put several dollars into the overflowing pot, but here's another couple of cents.

Monday's discussion helped me realize why my email remarks on terminology last week were almost a mirror image of what was proposed.  The enlightenment came through my attention being drawn to something I already knew, in fact: that the term "module" has a significantly different interpretation in typical hardware languages from in typical software languages.  And the proposed use reflected the hardware world interpretation.  Now P4 is aimed at the "network engineer", so a top-level question is whether such a person might expect the language to follow more hardware like conventions or more software like conventions.  On balance, I'd suspect the latter would be more appropriate.  So I'd incline to think of a "module" (or a "package" for that matter) to have the usual software interpretation (as in the P4 code base language Python), as basically a "collection of useful stuff" that shares a namespace.  The signature of a module is just the collection of all the types of the things in the module.  I think that this may be what's mentioned as "broad modularity" in the notes below, but must confess that I lapsed and missed hearing that particular remark in context on Monday.

Continuing in the software-style mindset, then objects are certainly things that can be instanced.  The blackbox use in the proposal can perfectly well be modelled via objects, but I realized on Monday that the important aspect (kind-of obvious given it's a black box of course) is that the object type declaration contains abstract methods only (i.e., no implementations of the methods).  My point, illustrated by email examples last week, is that the various pieces of a P4 system can also be modelled by objects: the current syntax does not explicitly mention objects or methdds, but the various special-case pieces of syntax are essentially defining (or completing) methods for these objects.  In short, I think that the "abstract" part is more important than the "object" part when talking of black boxes, so probably the thing to be emphasized in the syntax.  Then we might feel more confident about treating things with the proposed "module" syntax as also having (non-abstract) "object" syntax.

Maybe Peter has a point, and talking of "components" would be more neutral.  Then one can talk about their "interfaces", and be less loaded towards methods on one software hand, and wires on the other hardware hand.


p.s. Also thanks to Peter for reminding me of: http://www.solearabiantree.net/namingofparts/namingofparts.html

From: P4-design [mailto:p4-design-bounces at p4.org] On Behalf Of Peter Newman (petenewm)
Sent: Friday, August 07, 2015 10:44 AM
To: Leo Alterman
Cc: p4-design at p4.org
Subject: [P4-design] Naming of Parts

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.


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)


  *   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<mailto:P4-design at p4.org>
Listinfo - http://mail.p4.org/mailman/listinfo/p4-design_p4.org

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150807/a850df7e/attachment-0001.html>

More information about the P4-design mailing list