[P4-design] 3rd working meeting minutes

Changhoon Kim chang at barefootnetworks.com
Tue Aug 11 21:04:22 EDT 2015


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 Luxembourghttp://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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150811/675cff29/attachment-0001.html>


More information about the P4-design mailing list