Toward Working Group pages

_config.yml

@@ -12,6 +12,9 @@ collections:
   drafts:
     output: true
     permalink: /blog/drafts/:slug.html
+  minutes:
+    output: true
+    permalink: /minutes/:path.html
 
 social:
   - title: twitter
@@ -23,7 +26,7 @@ markdown: kramdown
 highlighter: rouge
 permalink: none
 paginate: 5
-include: ['_drafts','_pages','_events']
+include: ['_drafts','_events','_minutes','_pages']
 exclude: ["less","node_modules","Gruntfile.js","package.json"]
 plugins:
     - jekyll-paginate

_layouts/page.html

@@ -4,4 +4,10 @@
 <header id="header" class="page-header">
 </header>
 
+<div class="container">
+<div class="row">
+<div class="col-lg-12 col-md-12">
 {{ content }}
+</div>
+</div>
+</div>

_minutes/2017-10-23-ldwg-minutes.md

@@ -0,0 +1,84 @@
+---
+layout: page
+title: "October 23, 2017"
+date: 2017-10-23
+author: "Nate Foster"
+category: ldwg
+---
+
+Attendees: Nate Foster (Cornell), Andy Fingerhut (Cisco), Chris
+Sommers (IXIA), Kingshuk Mandal (IXIA), Cole Schlesinger, Milad
+Sharif, Calin Cascaval (Barefoot), Mihai Budiu (Vmware), Andy Keep
+(Cisco), Joe Tardo (Broadcom)
+
+First meeting since spring. Goal is to discuss accumulated issues and
+prioritize proposals for new language features.
+
+# Accumulated Issues    
+
+* [Issue 273](https://github.com/p4lang/p4-spec/issues/273)
+    - reading undefined values
+        - for portability we would like to see whether there is some pattern that we can agree on
+    - **AI** @jafingerhut to generate PR that clarifies behavior 
+
+* [Issue 284](https://github.com/p4lang/p4-spec/issues/284)
+    - header stacks: do P4_X allow holes or not?
+    - Goal: make sure that P4_16 and bmv2 are in sync, and ensure that the translation from P4_14 is correct
+    - **AI** @jnfoster to generate PR that harmonizes specifications
+
+* [Issues 294](https://github.com/p4lang/p4-spec/issues/294) and [Issue 331](https://github.com/p4lang/p4-spec/issues/331)
+    - do we allow compile time constants into expressions?
+    - **AI**: @jnfoster to convert into community project
+
+* [Issue 364](https://github.com/p4lang/p4-spec/issues/364)
+    - instantiation context and constructor params
+    - matrix:
+        - calling parsers from controls (and reverse) is not well defined due to the nature of operations (and restrictions).
+        - externs have a clear interface for the data plane
+        - tables can be wrapped into controls and passed around
+        - tables in parsers -    - we could consider it
+    - externs instantiated in packages?
+        - package bodies
+    - **AI** @ccascaval to re-merge
+
+* P4-14 fixes
+    - Ali Kheradmand at UIUC has been modeling P4_14 in K
+    - Mihai: what happens to legacy code if the semantics changes?
+        - owners of legacy code should push back
+    - **AI** @jnfoster to encourage Ali finish these as PRs and then tackle P4_16
+
+* [Issue 342](https://github.com/p4lang/p4-spec/issues/342)
+    - bit vector structs within headers or structs
+    - there is a PR 
+    - ordering constraints depending on how it is used
+    - **AI** @akeep to organize a small subgroup to explore the notion of serializable types with @jafingerhut, @mbudiu-vmware, @sethfowler
+
+* [Issue 198](https://github.com/p4lang/p4-spec/issues/198) and [Issue 341](https://github.com/p4lang/p4-spec/issues/341)
+    - issues: syntax ({} vs. []), holes, defaults, semantics of empty tuple
+    - `setValid` and `setInvalid` operations
+    - proposed extern: `void zero<T>(out T v)`?
+    - **AI** @jnfoster to convert into community project
+
+* [Issue 151](https://github.com/p4lang/p4-spec/issues/151) and [Issue 76](https://github.com/p4lang/p4-spec/issues/76)
+    - calling actions from parsers
+    - function definition: trivial to implement in the compiler (since basically already implemented)
+    - virtual functions: allowed only in the body of the extern
+    - named params
+    - **AI** @milad14000 to organize a small subgroup
+
+* [Issue 51](https://github.com/p4lang/p4-spec/issues/51)
+    - field list: function that takes a struct and returns a tuple.
+    - not a field reference.
+    - **AI** @ccascaval to organize a small subgroup
+
+* [Issue 264](https://github.com/p4lang/p4-spec/issues/264)
+    - operations on varbits
+    - **AI** @jnfoster to punt to later
+
+# Next Version
+
+* It's time to thinking about new features for next language version
+
+# Future meetings
+
+* Resolved to meet about once a month for now

_minutes/2017-11-27-ldwg-minutes.md

@@ -0,0 +1,231 @@
+---
+layout: page
+title: "November 27, 2017"
+date: 2017-11-27
+author: "Nate Foster"
+category: ldwg
+---
+
+Attendees: Gordon Brebner (Xilinx), Mihai Budiu (VMware),
+Chris Dodd (Barefoot), Andy Fingerhut (Cisco), Andy Keep (Cisco),
+James Coole (Cisco), Nate Foster (Cornell), Calin Cascaval (Barefoot),
+Matt Massey (Cisco), Joe Tardo (Broadcom)
+
+# Agenda:
+
+* [5 minutes] status and roadmap
+  - discussion lead: @gbrebner
+
+* [25 minutes] clarify operations on invalid headers 
+  - discussion lead: @jafingerhut
+  - GitHub issues: #273 and #285
+  - Pull Request: https://github.com/p4lang/p4-spec/pull/450
+
+* [25 minutes] clarify semantics of header stacks
+  - discussion lead: @jnfoster
+  - GitHub issues: #284
+  - Pull Request: https://github.com/p4lang/p4-spec/pull/501
+
+* [25 minutes] proposal for serializable types
+  - discussion lead: @akeep
+  - GitHub issues: #342
+  - Discussion document: https://github.com/akeep/p4-proposals/blob/master/serializable.pdf
+
+* [10 minutes] open
+
+
+# Status and roadmap
+
+Pick up on selected action items from last meeting.
+
+Plan: Create a P4_14 v1.0.5 maintenance release, and a P4_16 v1.0.1
+maintenance release.
+
+Still open for ideas for a P4_18 language.  Gordon Brebner has some
+ideas there.
+
+
+
+# Clarify operations on invalid headers 
+
+Action items: @jafingerhut
+
+Changes to be made to existing pull request:
+- Pull Request: https://github.com/p4lang/p4-spec/pull/450
+
+Add clarification that for fields with enum type, an unspecified value
+might not be equal to _any_ of the enum values defined within the enum
+declaration.  This may violate compiler assumptions in if-then-else or
+select expressions intended to be exhaustive.
+
+Make explicit that reading a header field could be in a header_union
+or a header stack, in addition to the already-mentioned header type.
+
+Perhaps: Add one example of a ternary field match in a table with all
+bit positions wild-carded, as one way to ignore an unspecified value.
+
+
+
+For a header union, specify that invalid header field write must not
+change validity of any header_union members.
+
+Remove the last added paragraph.  Add a paragraph near the beginning
+of the specification, with wording similar to this:
+
+    "It is understood that some implementations may be unable to
+    implement the behavior defined here in all cases.  They should
+    document where they deviate from this specification."
+
+No objections to leaving the 'safe behavior' proposed in the pull
+request as the default of the language spec.
+
+
+
+# Clarify semantics of header stacks
+
+@jnfoster went through the known differences between operations on
+header stacks in the P4_14 and P4_16 specification documents, and the
+bmv2 simple_switch implementation.
+
+   https://github.com/jafingerhut/p4-guide/blob/master/README-header-stacks.md
+
+@jnfoster had discussed with Antonin Bas before the meeting on this
+issue, and Antonin is willing to update bmv2 to whatever the language
+working group decides when updating the language specs.
+
+Concerns:
+
++ We should not change the P4_14 language specification in ways that
+  break extant P4_14 programs in significant ways.
+
++ There should be reasonable ways to auto-translate a P4_14 to P4_16
+  program with equivalent behavior.
+
+Proposals:
+
++ Update P4_14 spec for add_header and remove_header, so they no
+  longer have the behavior of 'shifting' existing elements within a
+  header stack.  Instead, they will only have an effect on the one
+  header stack element that is the argument of the operation.
+
++ Change bmv2 implementation so that push and pop shift all indices of
+  the header stack, not only the elements in range [0, next-1] as it
+  does today.
+
++ In P4_14 and P4_16 language specs, explicitly allow extract() calls
+  into header stack elements with constant indexes.  @cdodd: Some
+  P4_14 programs use this today.  Such an operation will have no
+  effect on the last or next index state maintained in the parser.
+  Such an extract() operation could create holes, and is allowed to do
+  so.
+
+  + mbudiu - The P4 compiler could warn if the same header stack is
+    ever extract'ed into via constant indices in some places, and next
+    in other places, warning the user that they are doing this.  It is
+    not an error, but since this situation can easily lead to
+    confusing behavior, they might not have intended to do so.
+
++ Keep P4_14 push() operation with behavior of making new pushed
+  headers valid, and keep P4_16 push_front() method with behavior of
+  making new pushed headers invalid.  Any P4_14 to P4_16 translator
+  should translate this in P4_14:
+
+    push(header_stack, N);
+
+  into this in P4_16:
+
+    header_stack.push_front(N);
+    header_stack[0].setValid();
+    ...
+    header_stack[N-1].setValid();
+
+  TBD: whether the translator should also add statements after the
+  setValid() calls to initialize all header fields to 0.
+
+mbudiu - would be good to have test cases that cover all of this
+behavior.
+
+
+
+# Proposal for serializable types
+
+- GitHub issues: #342
+- Discussion document: https://github.com/akeep/p4-proposals/blob/master/serializable.pdf
+
+akeep described proposal for serializable types.
+
+What is the goal of a serializable type?
+
+mbudiu - We need to be careful what the goal is here.  For example,
+header_union emit would leave out which member header is valid, so you
+could not reconstruct the original.
+
+akeep - The same is true of ordinary headers, since validity bit is
+not emitted.
+
+Goal of serializable type modifier - could be used as a modifier for
+any argument of any control, extern method, parser, etc., meaning that
+callers must supply a value with a serializable type for that
+argument.
+
+akeep - e.g. Maybe you would want hash functions that require their
+argument data to be serializable.
+
+jnfoster - keys to a table are another example that you may want to be
+serializable.
+
+akeep - also digest contents.
+
+akeep - Currently emit's restriction on argument types are described
+in prose in the language spec.  By introducing 'serializable' types,
+we can bring this explicitly into the language itself, and then allow
+that type modifier to be used in other places.
+
+mbudiu - I added a comment on Github that we could use P4_16
+annotations for this.
+
+akeep - I am not in favor of P4_16 annotations for this purpose,
+because in the language spec it is sometimes unclear whether some
+annotations are ignorable by an implementation, vs. others that an
+implementation must handle.
+
+cdodd - If you want to use serializable for multiple scenarios,
+e.g. emit and table keys, are you sure that the same set of things
+should be serializable in all of those use cases, or should they be
+slightly different sets of objects in different use cases?
+
+akeep - My thinking is that there would be only one format for
+serializing these things.
+
+mbudiu - Another approach to this problem is to define extern methods
+like serialize_to_bit() or serialize_to_xml(), etc. and they write
+data into a buffer somewhere.
+
+akeep - The assumption so far with this 'serializable' keyword is that
+we do want to define a wire format for serializable types, and it
+should be the same wire format used by different P4 implementations.
+
+The intent is to extend serializable to include:
+
+bit<W> int<W> bool enum, over and above the existing header, header
+stack, header_union.  Also, structs nested arbitrarily that "bottom
+out" in serializable type.
+
+cdodd - Important to keep the multiple of 8 bit restriction on emit
+calls, if emit was generalized to take anything serializable according
+to this process.
+
+akeep - For anyone interested in contributing to this proposal or
+providing feedback on it, please participate in this public Github
+repository:
+
+    https://github.com/akeep/p4-proposals
+
+Proposal: Take the feedback from this discussion, and refine the
+current proposal.
+
+
+# Next meeting
+
+Early January, to keep on monthly schedule.  Possible extra meeting
+on 18 December if sufficient progress made on outstanding issues.

_pages/ldwg.md

@@ -0,0 +1,41 @@
+---
+layout: page
+title: "Language Design Working Group"
+description: "Language Design Working Group"
+permalink: ldwg/
+---
+
+## Charter
+
+The Language Design Working Group is responsible for developing and
+maintaining the P4 language specification and accompanying software
+artifacts.
+
+## Co-Chairs
+
+* Gordon Brebner (Xilinx)
+* Nate Foster (Cornell)
+
+## Mailing Lists
+
+* [Sign up](http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org)
+* [Archive](http://lists.p4.org/pipermail/p4-design_lists.p4.org/)
+
+## Code
+
+* Specifications [https://github.com/p4lang/p4-spec/](https://github.com/p4lang/p4-spec/)    
+* P4 Compiler [https://github.com/p4lang/p4c/](https://github.com/p4lang/p4c/)
+* Behavioral Model version 2 [https://github.com/p4lang/bmv2/](https://github.com/p4lang/bmv2/)
+
+## Meeting Minutes
+<ul>
+{% for minutes in site.minutes %}
+{% if minutes.category == 'ldwg' %}
+<li>
+  <a href="{{ minutes.url | prepend: site.baseurl }}">{{ minutes.title }}</a>
+</li>
+{% endif %}
+{% endfor %}
+</ul>
+
+&nbsp;