[P4] Fwd: Re: [P4-design] P4_14 changes
Sándor Laki
lakis at elte.hu
Fri Nov 4 08:33:13 CET 2016
-------- Forwarded Message --------
Subject: Re: [P4-design] P4_14 changes
Date: Thu, 3 Nov 2016 17:30:18 -0700
From: Changhoon Kim <chang at barefootnetworks.com>
To: p4-design at lists.p4.org <p4-design at lists.p4.org>
CC: Amin Vahdat <vahdat at google.com>
All,
Since we discussed this minor revision last week Monday, a few members
additionally expressed their support on this minor revision of P4_14.
Given that we had enough feedback and support calls, I'll go ahead and
replace the v1.0.2 version with this one (attached).
I will also withdraw the v1.1 spec from the P4.org web page and share
the following news to set the stage for P4_16.
/"The P4 Language Design Working Group is working actively to produce
and publish a major revision of P4 (P4_16) soon. This new public
pre-release spec will offer the following additional capabilities
respective to the current widely-adoped P4 (P4_14): /
/
/
/- Support for architectural heterogeneity (language-architecture
decoupling)/
/- Support for functional heterogeneity/
/- Strong types/
/- Improvement on code re-usability/
/"/
/
/
/
/
On Sun, Oct 23, 2016 at 12:31 PM, Changhoon Kim
<chang at barefootnetworks.com <mailto:chang at barefootnetworks.com>> wrote:
All,
Based on some feedback from a few p4-design members, we made a few
more minor updates to this P4_14 v1.0.3 draft. Again, the main goal
of all these changes is making the reference P4 software switch
(BMv2) and the P4_14 spec as close as possible in terms of primitive
actions supported and their details. This will help P4 users --
especially new P4 writers -- learn P4 programming more easily with
few surprises.
Section 15.3 (page 67 and 68) has the summary of changes.
Let's also review this tomorrow and try to approve.
-- Chang
On Wed, Sep 28, 2016 at 11:09 PM, Vladimir Gurevich
<vag at barefootnetworks.com <mailto:vag at barefootnetworks.com>> wrote:
Hi Chang,
1. What is the status of other arithmetic and logical
primitives beyond add()? They are available in
BMv2-simple_switch and some of them are being used in
switch.p4 for example (bit_xor() to name one)?
2. What's the status of the
primitive modify_field_rng_uniform(dst, lower_boundary,
upper_boundary) ? It has been added to BMv2-simple_switch a
while ago, is used in switch.p4 and in any case people need
some sort of randomness
3. What's the decision on execute_meter() and count() in
relation to direct meters and counters? There were two
schools of thought:
1. They are not needed and are implicitly added to all
actions referenced in the table
2. There should be a special form of these primitives
(count(counter_ref) and execute_meter(meter_ref), i.e.
without index/destination field) that can OPTIONALLY be
added to some or all actions, mentioned in the table,
therefore providing more flexibility to the user and
reducing the amount of implicitly generated code
Thanks,
Vladimir
On Tue, Sep 27, 2016 at 11:11 PM, Changhoon Kim
<chang at barefootnetworks.com <mailto:chang at barefootnetworks.com>>
wrote:
Team,
We haven't had time to discuss these changes at our last
meeting. Gordon, Peter, and a few other told me they're in
favor of these tidying-up changes for P4_14. Please give me
a holler in a day or two if you oppose to these. Otherwise,
I'll publish these changes via P4.org late Friday.
Thanks.
-- Chang
On Thu, Sep 22, 2016 at 10:03 AM, Peter Newman (petenewm)
<petenewm at cisco.com <mailto:petenewm at cisco.com>> wrote:
Chang,
Thanks for tidying this up. I had noticed that the
primitive actions in switch.p4 did not exactly agree
with the spec. This looks fine.
—Peter
On Sep 20, 2016, at 6:11 PM, Changhoon Kim
<chang at barefootnetworks.com
<mailto:chang at barefootnetworks.com>> wrote:
Hi P4 designers,
While we're all working busily to review the P4_16
proposal and trying to solidify it, I'd like to make a
couple proposals related to a completely different
topic: P4_14.
1) The currently widely adopted P4_14 spec is the v1.0.2
version. All the public p4lang code out there is largely
based on this spec, and I expect that this version will
continue to be used for a while, as we'll phase into
P4_16. Unfortunately there are a few minor discrepancies
between the v1.0.2 spec and what's actually implemented
in p4lang/p4-hlir and BMv2, causing confusion to P4
beginners and writers right now. I think it'll be very
helpful for the P4 community if we fix those
discrepancies quickly. The attached draft -- which is
tentatively versioned v1.0.3, but could be officially
named P4_14 -- is an attempt to fix those issues. The
extent of change is minimal, and the following list
summarizes it. There's a revision history in the
Appendix as well. I suggest we review this version
quickly and publish it, replacing the v1.0.2 spec.
* Page 29: removed register layout in register
declaration.
* removed bracket-based register referencing from
o the parameters of modify_field, add_to_field and
add primitives
* Page 27, Section 7 intro.
* Page 47, 9.1.2 Parameter Binding
* page 87, example code: Use register_read/write
primitives instead.
# page 32: fixed execute_meter,
modify_field_with_hash_based_offset, added
register_read/write
# pages 37: fixed the name, description and parameter
ordering of modify_field_with_hash_based_offset.
# pages 40, 41: fixed execute_meter and added
register_read/write primitives.
# Changed optional parameters of push, pop, resubmit,
recirculate, clone_* primitives to mandatory parameters.
Revised pop/push descriptions accordingly.
2) The v1.1 spec is currently in a pre-release review
state. It hasn't gotten much traction, and we weren't
able to secure the necessary code contributions that
fully realize this version either. Meanwhile P4_16
offers language features addressing all the goals we
wanted to achieve with v1.1, including extern types,
stronger type, expression support, etc., and even more.
Given that we'll publish P4_16 soon, I suggest we
withdraw the v1.1 spec. That way, we'll avoid
proliferation of spec variations and minimize confusion.
Let me know your thought on this. If there's no strong
objection, I'll go ahead and make these changes by next
week.
Thanks.
-- Chang
<p4_14_v1.0.3-draft.pdf>_______________________________________________
P4-design mailing list
P4-design at lists.p4.org <mailto:P4-design at lists.p4.org>
http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org
<http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org>
_______________________________________________
P4-design mailing list
P4-design at lists.p4.org <mailto:P4-design at lists.p4.org>
http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org
<http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org>
---
Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/p4/attachments/20161104/0a850074/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p4.pdf
Type: application/pdf
Size: 1160313 bytes
Desc: not available
URL: <https://plc.inf.elte.hu/pipermail/p4/attachments/20161104/0a850074/attachment-0001.pdf>
-------------- next part --------------
_______________________________________________
P4-design mailing list
P4-design at lists.p4.org
http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org
More information about the P4
mailing list