[P4-design] P4_14 changes

Changhoon Kim chang at barefootnetworks.com
Sun Oct 23 15:31:03 EDT 2016


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> 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> 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> 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>
>>> 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
>>>    - 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
>>> http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org
>> _______________________________________________
>> P4-design mailing list
>> P4-design at lists.p4.org
>> http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20161023/f954589a/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p4_14 - v1.0.3.pdf
Type: application/pdf
Size: 1207229 bytes
Desc: not available
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20161023/f954589a/attachment.pdf>

More information about the P4-design mailing list