[P4-design] 3rd working meeting minutes

Yatish Kumar yatish.kumar at corsa.com
Wed Aug 12 11:57:56 EDT 2015


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/fc2822fe/attachment-0001.html>


More information about the P4-design mailing list