[P4-discuss] Fwd: [P4-dev] Comments and questions on Dec 16, 2016 draft of P4_16 spec

Antonin Bas antonin at barefootnetworks.com
Tue Jan 10 03:33:20 EST 2017

---------- Forwarded message ----------
From: Antonin Bas <antonin at barefootnetworks.com>
Date: Tue, Jan 10, 2017 at 12:32 AM
Subject: Re: [P4-dev] Comments and questions on Dec 16, 2016 draft of P4_16
To: Andy Fingerhut <andy.fingerhut at gmail.com>
Cc: p4-dev <p4-dev at lists.p4.org>

Hi Andy,

Thanks for your feedback. I am not sure this mailing list is the best place
for you to publish comments on the spec. Let me forward your email to the
p4-discuss mailing list, as well as to some relevant people who have been
actively working on the spec.



On Sun, Jan 8, 2017 at 12:42 AM, Andy Fingerhut <andy.fingerhut at gmail.com>

> Overall, I like the P4_16 draft quite a bit.  Explicit deparsing seems to
> make more explicit and defined how output packets are constructed as
> compared to P4_14, for example.  The architecture model looks flexible
> enough for many useful scenarios.  I made some notes about possible
> mistakes, and a few questions, given below.
> Thanks,
> Andy Fingerhut
> Section 8.11.3 "Cubes"
> An example '8w0xFA &&& 0w0x0F' is given that violates the rule given
> earlier 'The mask &&& infix operator takes two arguments of the same
> bit<W> type'.  Probably the example should be '8w0xFA &&& 8w0x0F'?
> Section 11.8.2 "extract -- two arguments"
> The pseudocode refers to headerLvalue, similar to the one-argument
> extract pseudocode, but the parameter is called variableSizeHeader in
> this pseudocode.  Best to make the names match each other.
> Should the verify(bitsToExtract < headerLvalue.maxSize, ...) have '<='
> instead of '<'?  It seems it should be legal to extract up to
> headerLvalue.maxSize bits, inclusive?
> Section 12 "Control blocks" 'The architecture forbids the
> instantiation of parser instances within a control block'.  Does this
> mean P4 the language forbids this, or that some P4_16 architectures
> may forbid it, but others may allow it?  If the latter, that is
> surprising.  If the former, it seems clearer to say 'The P4 language
> forbids'.
> Typos:
> Section 11.9 "Parsing header stacks"
> 'erro' -> 'error' in 'sets the erro to'
> Section 12.2 "Tables"
> Remove first 'is' in phrase 'Note that the term is "table" is
> overloaded".
> D. Appendix: Open Issues
> The link "Portable Switch Architecture" is to
> http://p4.org/documents/psa.pdf but there is no file at that location.
> Section 12.1 Actions
> 'Some targets may impose additional restrictions on action bodies --
> e.g. only straight-line code, with no if statements or conditional
> expressions (?:).'
> I have not yet thought of a reason why such a restriction would be
> helpful in implementing a compiler for a target.  If control blocks
> can have arbitrarily nested 'if' statements that apply tables in the
> then and/or else branches, why not allow them in the actions, too?
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-discuss_lists.p4.org/attachments/20170110/daf19c25/attachment-0002.html>

More information about the P4-discuss mailing list