From 62ebab69112fff478bb05ccfe693556bed557fd2 Mon Sep 17 00:00:00 2001 From: Nate Foster Date: Wed, 27 Dec 2017 12:53:05 -0500 Subject: [PATCH 1/3] Add minutes from LDWG meetings and LDWG page --- _config.yml | 5 +- _layouts/page.html | 6 + _minutes/2017-10-23-ldwg-minutes.md | 84 ++++++++++ _minutes/2017-10-23-ldwg-minutes.md~ | 84 ++++++++++ _minutes/2017-11-27-ldwg-minutes.md | 231 +++++++++++++++++++++++++++ _minutes/2017-11-27-ldwg-minutes.md~ | 231 +++++++++++++++++++++++++++ _pages/ldwg.md | 41 +++++ 7 files changed, 681 insertions(+), 1 deletion(-) create mode 100644 _minutes/2017-10-23-ldwg-minutes.md create mode 100644 _minutes/2017-10-23-ldwg-minutes.md~ create mode 100644 _minutes/2017-11-27-ldwg-minutes.md create mode 100644 _minutes/2017-11-27-ldwg-minutes.md~ create mode 100644 _pages/ldwg.md diff --git a/_config.yml b/_config.yml index b9343921..0f1c2cd9 100755 --- a/_config.yml +++ b/_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 diff --git a/_layouts/page.html b/_layouts/page.html index 7041828d..ed1a5050 100644 --- a/_layouts/page.html +++ b/_layouts/page.html @@ -4,4 +4,10 @@
+
+
+
{{ content }} +
+
+
diff --git a/_minutes/2017-10-23-ldwg-minutes.md b/_minutes/2017-10-23-ldwg-minutes.md new file mode 100644 index 00000000..4ab8a50d --- /dev/null +++ b/_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(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 \ No newline at end of file diff --git a/_minutes/2017-10-23-ldwg-minutes.md~ b/_minutes/2017-10-23-ldwg-minutes.md~ new file mode 100644 index 00000000..226826a5 --- /dev/null +++ b/_minutes/2017-10-23-ldwg-minutes.md~ @@ -0,0 +1,84 @@ +--- +layout: page +title: "LDWG Minutes 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(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 \ No newline at end of file diff --git a/_minutes/2017-11-27-ldwg-minutes.md b/_minutes/2017-11-27-ldwg-minutes.md new file mode 100644 index 00000000..3999a898 --- /dev/null +++ b/_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 int 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. \ No newline at end of file diff --git a/_minutes/2017-11-27-ldwg-minutes.md~ b/_minutes/2017-11-27-ldwg-minutes.md~ new file mode 100644 index 00000000..8571cf64 --- /dev/null +++ b/_minutes/2017-11-27-ldwg-minutes.md~ @@ -0,0 +1,231 @@ +--- +layout: page +title: "LDWG Minutes 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 int 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. \ No newline at end of file diff --git a/_pages/ldwg.md b/_pages/ldwg.md new file mode 100644 index 00000000..66cad0d1 --- /dev/null +++ b/_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 +
    +{% for minutes in site.minutes %} +{% if minutes.category == 'ldwg' %} +
  • + {{ minutes.title }} +
    • +{% endif %} +{% endfor %} +
+ +  \ No newline at end of file From 7602dca8fec35d4f29f49bf7f3dc765e924e9481 Mon Sep 17 00:00:00 2001 From: Nate Foster Date: Wed, 27 Dec 2017 13:30:19 -0500 Subject: [PATCH 2/3] Remove Emacs backup files --- _minutes/2017-10-23-ldwg-minutes.md~ | 84 ---------- _minutes/2017-11-27-ldwg-minutes.md~ | 231 --------------------------- 2 files changed, 315 deletions(-) delete mode 100644 _minutes/2017-10-23-ldwg-minutes.md~ delete mode 100644 _minutes/2017-11-27-ldwg-minutes.md~ diff --git a/_minutes/2017-10-23-ldwg-minutes.md~ b/_minutes/2017-10-23-ldwg-minutes.md~ deleted file mode 100644 index 226826a5..00000000 --- a/_minutes/2017-10-23-ldwg-minutes.md~ +++ /dev/null @@ -1,84 +0,0 @@ ---- -layout: page -title: "LDWG Minutes 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(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 \ No newline at end of file diff --git a/_minutes/2017-11-27-ldwg-minutes.md~ b/_minutes/2017-11-27-ldwg-minutes.md~ deleted file mode 100644 index 8571cf64..00000000 --- a/_minutes/2017-11-27-ldwg-minutes.md~ +++ /dev/null @@ -1,231 +0,0 @@ ---- -layout: page -title: "LDWG Minutes 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 int 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. \ No newline at end of file From f7327574bc08de3cd6a4afde6a402802a783c05e Mon Sep 17 00:00:00 2001 From: Nate Foster Date: Fri, 16 Mar 2018 12:16:43 -0400 Subject: [PATCH 3/3] Small fixes --- _pages/ldwg.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_pages/ldwg.md b/_pages/ldwg.md index 66cad0d1..0958a962 100644 --- a/_pages/ldwg.md +++ b/_pages/ldwg.md @@ -18,8 +18,8 @@ artifacts. ## 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/) +* [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