[P4-dev] move parser pointer forward

Salvatore Signorello salvatore.signorello at uni.lu
Tue Aug 4 16:45:15 EDT 2015


Peter,

thank you for the feedback, more inline

Best,
Salvatore

On Tue, 2015-08-04 at 09:36 -0700, Peter Newman 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.

Exactly, unfortunately I think that this is not doable through the
current specification, unless you refer to fields of the same header to
calculate the variable-length field size. For example, the following
header definition

header_type foo_t {
    fields {
        blah : *;
    }
    length :  ?; // you can just use header fields of foo_t to compute
something here
    max_length : x;  (both max_length and length are mandatory in
presence of a variable-length field)
}

does generate a semantic error.


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

I agree with you again. In fact I wonder if the language, as it is,
allows you to parse out only things you know how to parse and to skip
the rest. Btw, I would like to write out an example before claiming
something wrong.

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


More information about the P4-dev mailing list