[P4-design] Rough notes from 10/24 meeting

Nate Foster jnfoster at cs.cornell.edu
Mon Oct 24 18:43:14 EDT 2016

Calin has ported the spec to Makodo, which is a Markdown-style format that
can generate HTML and LaTeX and PDF. We will shift to this version going
forward, which will save Mihai the pain of having to manually keep track of
and merge all changes.

PDFs: Should we publish a PDF for people who don't want to install LaTeX,
etc.? Maybe not since it would cause issues with merges. Calin will set up
a GitHub pages so we can have the rendered versions of the document.

Graphics: we should convert the PNGs that were scraped from the old
document into some kind of vector graphics format. People who are
interested in this will work on this in the background.

One big file vs. lots of smaller files: This is sort of a matter of taste.
The person who did the hard work to port the specification prefers one big
file so we'll go with that for now.

Revision Process: anyone can edit and make pull requests. They should be as
narrow as possible. Changes should be reviewed with "+1s" and committed by
those authorized to do so.


* #78 concerns use of the word "prototypes." P4_16 doesn't really have
C-style prototypes. Action item: this has been resolved in the
specification and the issue will be closed.

* #77 concerns namespaces and path prefixes. Action item: replacing path
prefixes with a simpler design that allows downward navigation by a single
name (for error and enum). Think about what should happen with multiple
declarations of error types with the same name.

* #63 concerns multiple definitions of checksum units. Action item: Nate to
verify in Madoko version and close.

* #59 concerns tuple types. These have now been added to the compiler and
the spec. Action items:
- explore if projections can be added.
- separately, think about header stacks.

* #48 concerns the concurrency model. Section 17.4.1 sketches a draft for a
concurrency model with an @atomic annotation. Action item: this has been

* #43 concerns calling conventions Action items: this has already been

* #86 concerns legacy annotations for special header fields (Ethernet,
IPv4, etc.) The proposal is to delete these from the spec, since the
Control API is the subject of another document. Action item: these will be
removed and then we will close the issue.

* #54 concerns reserving annotations for use by the compiler. The proposal
might be to use "@p4_" or lowercase names. Architecture-specific ones might
use a prefix convention. Action item: develop a proposal than this can be

* #55 concerns parser <-> control interactions. Action item: add a few
lines to the spec stating the semantic condition and then we'll close this.

* #58 concerns generalizing switch statements. Action item: Nate, Mihai and
Chris to explore the implementability of this.

We closed with a long-winded discussion of the philosophy of DSLs, P4_16,
general-purpose features, etc.

Calin observes that we don't have enough experience implementing programs
in P4_16. This makes it hard to evaluate the language design. We should
write more code.

For example, want to be able to extend OVS (which does a lot of standard
processing) with P4 custom snippets.

There are a lot of examples from Netronome of things that are difficult or
impossible to express in P4_14. This might be a good source of examples.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20161024/dbe2391e/attachment-0002.html>

More information about the P4-design mailing list