[P4-design] 3rd working meeting minutes

Gordon Brebner Gordon.Brebner at xilinx.com
Wed Aug 12 11:38:10 EDT 2015


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<mailto: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<mailto: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<mailto: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<mailto: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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150812/8ddc4629/attachment-0001.html>


More information about the P4-design mailing list