[P4-design] 3rd working meeting minutes

Changhoon Kim chang at barefootnetworks.com
Wed Aug 12 12:11:18 EDT 2015


I second Yatish's suggestion. Addressing just packet-update requirements
would probably give us the biggest bang for buck.

On Wed, Aug 12, 2015 at 8:57 AM, Yatish Kumar <yatish.kumar at corsa.com>
wrote:

> I would prefer if we kept it to packet updates.
>
> Yatish
>
>
> On Wed, Aug 12, 2015 at 11:38 AM, Gordon Brebner <
> Gordon.Brebner at xilinx.com> wrote:
>
>> I’m certainly interested in joining in a deparser activity – having this
>> completely implicit has always seemed a restriction, bordering on being
>> obfuscation.
>>
>>
>>
>> Whether it’s “small and contained” would depend on the scope.  Potentially,
>> a deparser’s capability could range from modest, pretty static updates
>> to the packet (as now) all the way through to being a packet generator
>> loosely stimulated by packet arrivals and other events (via SAR en route).
>> Would the thinking be that this deparser exercise still operates on the
>> “one packet, one packet out” (modulo cloning) forwarding assumption?  That
>> is, it’s essentially about packet updates.
>>
>>
>>
>> Gordon.
>>
>>
>>
>>
>>
>> *From:* P4-design [mailto:p4-design-bounces at p4.org] *On Behalf Of *Changhoon
>> Kim
>> *Sent:* Tuesday, August 11, 2015 6:04 PM
>> *To:* Leo Alterman
>> *Cc:* p4-design at p4.org
>> *Subject:* Re: [P4-design] 3rd working meeting minutes
>>
>>
>>
>> This is a good segue into another topic I wanted to run by the
>> working-group members. The deparser features in the current P4 spec is not
>> expressive enough to be able to enable some advanced deparser
>> specifications (e.g., specifying a particular order of TLV-style header
>> options).
>>
>>
>>
>> Would some members be interested in introducing some new language
>> constructs for deparser? I presume it's a relatively small and contained
>> work item.
>>
>>
>>
>> -- Chang
>>
>>
>>
>> On Mon, Aug 10, 2015 at 4:02 PM, Leo Alterman <leo at barefootnetworks.com>
>> wrote:
>>
>> Hi Salvatore,
>>
>>
>>
>> Thanks for the comments, responses inline:
>>
>>
>>
>> > - several IPv4 options have variable length, e.g., LSRR, timestamp and
>> others; so you need a variable length field into the option_A header type
>> and you need a component/blackbox/whatever that can take another header
>> field as parameter:
>>
>>
>>
>> Both of the option headers in this example were intended to be fixed
>> length options. Indeed, variable-legnth options would need a star field. As
>> defined, the counter's increment method can already take a header field as
>> its argument.
>>
>>
>>
>> > (why aren't option_A and option_B arrays too?)
>>
>>
>>
>> They could be - it's the difference between allowing those options to be
>> repeated in the header or not. It's probably important to clarify in the
>> spec what happens when one extracts to an already-extracted instance (I
>> would lean towards an exception being triggered).
>>
>>
>>
>> > - as regards the struct ipv4_t, I think of it as an ordered memory
>> area, so if you define it like the following:
>>
>>
>>
>> While the struct's members are ordered, I would not assume that this
>> order reflects how data is actually deparsed to the wire - the spec
>> currently describes the wire ordering as being inferred from the parse
>> graph.
>>
>>
>>
>> That being said, you still bring up a good point: if the deparsing
>> mechanism of the language works by determining a fixed order of header
>> instances (either through the struct definition or through the parse
>> graph), it's difficult to preserve the order of header options like this.
>> We've been working through a few different approaches to deal with this,
>> and one possibility is to define a union-of-headers construct and allow
>> arrays of these unions. A union containing every possible header option is
>> defined, and then an array of these unions is parsed in the main option
>> processing loop. It's a more advanced case of TLV parsing that we didn't
>> want to address in our initial proposal, and is only an issue depending on
>> how the deparsing process is defined.
>>
>>
>>
>> ~Leo
>>
>>
>>
>>
>>
>> On Mon, Aug 10, 2015 at 6:23 AM, Salvatore Signorello <
>> salvatore.signorello at uni.lu> wrote:
>>
>> Hi all,
>>
>> On 08/07/2015 02:39 AM, Changhoon Kim wrote:
>>
>> [C] Barefoot proposes a blackbox that lets the parser keep such state,
>> and says this is enough to handle common headers like IPv4, Geneve, and TCP.
>>
>>
>> follow few things I've noticed skimming the ipv4_options_parser.p4 code.
>> They're probably all known to the Barefoot folks, if so, please just ignore
>> them.
>>
>> Best regards
>>
>>
>> The idea of the counter to parse recurrent similar fields sounds great,
>> but as showed into the code sample doesn't parse the IPv4 options for the
>> following reasons:
>>
>> - several IPv4 options have variable length, e.g., LSRR, timestamp and
>> others; so you need a variable length field into the option_A header type
>> and you need a component/blackbox/whatever that can take another header
>> field as parameter:
>>
>> header_type ipv4_option_A {
>>     fields {
>>         // Boilerplate
>>         bit<8> type;
>>         bit<8> len; (you cannot use 'length' as field_name, because this
>> is a reserved token id)
>>
>>         // Option A fields
>>         bit<*> foo;
>>     }
>>     length : len; // this is the header length in bytes
>>     max_length : 40;
>> }
>>
>>
>> parser parse_option_a {
>>         extract(ipv4.option_A);
>>         ipv4_byte_counter.increment(-ipv4.option_A.len);
>>         return options_loop;
>> }
>>
>>
>> - as regards the struct ipv4_t, I think of it as an ordered memory area,
>> so if you define it like the following:
>>
>> struct_type ipv4_t {
>>     header ipv4_base_t base;
>>     header ipv4_option_A option_A; (why aren't option_A and option_B
>> arrays too?)
>>     header ipv4_option_B option_B;
>>     header ipv4_option_padding padding[4]; (why 4? at max you need 3 to
>> fill a 4 bytes word when a 1B option is present)
>> }
>>
>> it does mean that you can have option_A then option_B then eventually
>> some padding. Indeed this is not true, as for example the "No operation"
>> option (RFC 791) is meant to align the beginning of the next option to a
>> 32bit boundary. So you might (I've not run any code to double-check it)
>> have:
>>
>> option_A[0] + option_B[0] + option_A[1] + option_B[0] (this time is an
>> 'end of options list', in RFC 791 too ) + padding[0]
>>
>>
>>
>>
>>
>> --
>>
>> Salvatore Signorello
>>
>> PhD student @ SecanLab
>>
>>
>>
>> Interdisciplinary Centre for Security, Reliability and Trust
>>
>> SnT, University of Luxembourg
>>
>> http://wwwen.uni.lu/snt/people/salvatore_signorello
>>
>>
>>
>> _______________________________________________
>> P4-design mailing list
>> P4-design at p4.org
>> Listinfo - http://mail.p4.org/mailman/listinfo/p4-design_p4.org
>>
>>
>>
>>
>> _______________________________________________
>> P4-design mailing list
>> P4-design at p4.org
>> Listinfo - http://mail.p4.org/mailman/listinfo/p4-design_p4.org
>>
>>
>>
>>
>> This email and any attachments are intended for the sole use of the named
>> recipient(s) and contain(s) confidential information that may be
>> proprietary, privileged or copyrighted under applicable law. If you are not
>> the intended recipient, do not read, copy, or forward this email message or
>> any attachments. Delete this email message and any attachments immediately.
>>
>>
>> _______________________________________________
>> P4-design mailing list
>> P4-design at p4.org
>> Listinfo - http://mail.p4.org/mailman/listinfo/p4-design_p4.org
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150812/f76a81d3/attachment-0001.html>


More information about the P4-design mailing list