[P4-design] P4_14 changes

Changhoon Kim chang at barefootnetworks.com
Thu Nov 3 20:30:18 EDT 2016


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>
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> 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/20161103/186f3ffd/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p4.pdf
Type: application/pdf
Size: 1160313 bytes
Desc: not available
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20161103/186f3ffd/attachment.pdf>


More information about the P4-design mailing list