[P4-design] 3rd working meeting minutes

Salvatore Signorello salvatore.signorello at uni.lu
Mon Aug 10 09:23:50 EDT 2015


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

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


More information about the P4-design mailing list