[P4-dev] move parser pointer forward

Mihai Budiu mbudiu at barefootnetworks.com
Tue Aug 4 13:30:30 EDT 2015


The truth is that P4 as it is does not really provide good support for
trailer processing.
(For example, the ethernet trailer is never mentioned anywhere in the spec.)

If one plans to handle trailers similar to headers it would indeed make
sense to have a "seek" or "skip" operation to jump over the payload. But
this is a discussion for the p4-design mailing list.

Mihai

On Tue, Aug 4, 2015 at 9:36 AM, Peter Newman <petenewm at cisco.com> wrote:

> Salvatore,
>
> I would define a packet header that contains a single variable length
> field designed to contain all of the information you wish to skip. The only
> requirement is that at run time the length of this variable length field
> can be calculated from the fields in the packet that occur before it.
>
> I would still solve the problem this way even if the P4 spec is augmented
> with TLV processing. It only takes one parse cycle to skip information. I
> am assuming it would take N parse cycles to process each TLV option. I
> would only spend the N parse cycles if I needed to access the information
> contained in the TLV fields.
>
> --Peter
>
> On 8/4/2015 1:10 AM, Salvatore Signorello wrote:
>
> Thank you all for your feedback,
>
> let's think for a moment of a protocol that needs to check a trailer
> field, and so that needs to skip a considerable portion of the packet
> (e.g., the upper layer payload), what does the P4 programmer do? Does he
> define dummy header for extracting the payload? I know that "extracting" at
> such a high level could mean many things, but imho still the language
> syntax is a bit counterintuitive if you keep such construct.
>
> I don't want to discuss the protocol I'm working on, because it is a
> research idea that is not running on any real device. So, I've quickly
> selected an existing protocol that could generate the same issue, that is,
> the Encapsulating Security Payload (ESP), to start brainstorming on.
>
> I will also try to write out the parsing of IPv6 extension headers,
> because I guess this is something needed even there. Have you already
> thought about those?
>
> Best,
> Salvatore
>
>
>
>
> On 08/03/2015 08:22 PM, Mihai Budiu wrote:
>
> Today this is the only mechanism to read a non-constant number of bytes
> (i.e., which depends on header data).
>
> Mihai
>
> On Mon, Aug 3, 2015 at 11:16 AM, Gordon Brebner <Gordon.Brebner at xilinx.com
> > wrote:
>
>> I think that a generic “skip n bytes” operation can be done using a
>> header with a single field of * width and a length expression to compute
>> the desired n.  Is this correct?
>>
>>
>>
>> Gordon.
>>
>>
>>
>>
>>
>> *From:* P4-dev [mailto:p4-dev-bounces at p4.org] *On Behalf Of *LJ Wobker
>> *Sent:* Monday, August 03, 2015 11:08 AM
>> *To:* Salvatore Signorello; p4-dev at p4.org
>> *Subject:* Re: [P4-dev] move parser pointer forward
>>
>>
>>
>> That's correct - there is no explicit "skip" functionality in the
>> parser.  Think of the parse tree as a continuous graph that walks through
>> the incoming bytestream in order: there are no gaps.  As Mihai suggests,
>> you can always just use a dummy header field for bytes that you don't care
>> about, although I would contend that in most cases it will make more sense
>> to just parse the header with a meaningful name.
>>
>>
>>
>> Let us consider a contrived case such as: RTP in UDP in ipv4 in
>> ethernet.  Let's further assume (again, contrived) that you know you
>> absolutely do not need to parse any of the specific fields within the UDP
>> header, but you need/want to be able to get to the RTP headers underneath.
>>
>>
>>
>> You could easily build a parse tree/header definition that treats the
>> entire UDP header as one field, instead of the component fields.  This
>> might or might not be simpler/easier/faster/cheaper for a given target or
>> compiler to handle, and it might (or might not!) be more convenient for the
>> P4 programmer.
>>
>>
>>
>> Original UDP header format from
>> p4factory/master/targets/switch/p4src/includes/headers.p4
>> <https://github.com/p4lang/p4factory/blob/master/targets/switch/p4src/includes/headers.p4>
>>
>>
>>
>> header_type udp_t {
>>
>>     fields {
>>
>> *        srcPort : 16;*
>>
>> *        dstPort : 16;*
>>
>> *        length_ : 16;*
>>
>> *        checksum : 16;*
>>
>>     }
>>
>> }
>>
>>
>>
>> Modified/ simpler version as described:
>>
>>
>>
>> header_type udp_t {
>>
>>     fields {
>>
>> *        meaningless_blob : 64;*
>>
>>     }
>>
>> }
>>
>>
>>
>>
>>
>> So that’s probably a longer answer than you really needed, but I figured
>> I’d write it out for posterity.
>>
>>
>>
>>
>>
>> --lj
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: P4-dev [mailto:p4-dev-bounces at p4.org] On Behalf Of Salvatore
>> Signorello
>> Sent: Monday, August 03, 2015 10:01 AM
>> To: p4-dev at p4.org
>> Subject: [P4-dev] move parser pointer forward
>>
>>
>>
>> Hi all,
>>
>>
>>
>> could someone confirm that the actual specification doesn't provide any
>>
>> construct to advance the parsing pointer except the "extract" one?
>>
>>
>>
>> Is it possible to skip the parsing of some fields without defining and
>>
>> extracting a header including them?
>>
>>
>>
>> Best,
>>
>> Salvatore
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> P4-dev mailing list
>>
>> P4-dev at p4.org
>>
>> Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org
>>
>> Archives - http://mail.p4.org/pipermail/p4-dev_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-dev mailing list
>> P4-dev at p4.org
>> Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org
>> Archives - http://mail.p4.org/pipermail/p4-dev_p4.org/
>>
>
>
>
>
> _______________________________________________
> P4-dev mailing listP4-dev at p4.org
> Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org
> Archives - http://mail.p4.org/pipermail/p4-dev_p4.org/
>
>
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at p4.org
> Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org
> Archives - http://mail.p4.org/pipermail/p4-dev_p4.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20150804/871bbd5d/attachment-0001.html>


More information about the P4-dev mailing list