Get size of header

[theojepsen]

How do you get the size of a header in P4? Here is an example of what I'm trying to do:

action set_len() {
    hdr.ipv4.totalLen = len(hdr.ipv4) + len(hdr.udp) + len(hdr.my_proto);
}

len should return the size of the header (in bytes). In Python you can do this with Scapy. E.g. use len(scapy.UDP()) to get the size of a UDP header (i.e. 8 bytes).

The best workaround that I've found is to use a #define to set all the header sizes at the begging of my program, e.g.

#define IP_HDR_SIZE  20
#define MY_PROTO_HDR_SIZE 12

However, this has caused my lots of headaches. I can't tell you how many times I've changed the number/size of header fields, forgetting to update the constant, causing me to waste hours troubleshooting parser errors.

This seems like something straight-forward to implement in the compiler, possibly in the front-end. Since this can be calculated statically at compile time, it should be target-agnostic.

[jnfoster]

What about variable length headers?

…

On Fri, Jul 27, 2018 at 6:21 PM theojepsen ***@***.***> wrote: How do you get the size of a header in P4? Here is an example of what I'm trying to do: action set_len() { hdr.ipv4.totalLen = len(hdr.ipv4) + len(hdr.udp) + len(hdr.my_proto); } len should return the size of the header (in bytes). In Python you can do this with Scapy. E.g. use len(scapy.UDP()) to get the size of a UDP header (i.e. 8 bytes). The best workaround that I've found is to use a #define to set all the header sizes at the begging of my program, e.g. #define IP_HDR_SIZE 20 #define MY_PROTO_HDR_SIZE 12 However, this has caused my lots of headaches. I can't tell you how many times I've changed the number/size of header fields, forgetting to update the constant, causing me to waste hours troubleshooting parser errors. This seems like something straight-forward to implement in the compiler, possibly in the front-end. Since this can be calculated statically at compile time, it should be target-agnostic. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#660>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABwi0py3gf9xEQuoOePQHszRxJSwi1UTks5uK5JegaJpZM4Vkvto> .

[theojepsen]

@jnfoster I was thinking about why this feature (get header size) is not part of the language, and variable length headers was the first thing that popped into mind. Obviously, this is not known statically at compile time.

Would it be possible to raise a compile-time exception if len() is called on variable length headers?

[mihaibudiu]

We could also define it to return the max size of the header. We probably should return the size in bits. An important question is whether we promise this to be a compile-time constant. This may cause some difficulties in the implementation since we need to know all types before we can compute widths, but we can probably work it out. I will try to see whether we can work it out.

Another question is whether this applies to types aka sizeof, or just to instances. In the latter case we can make it like a method call.

[jafingerhut]

Thoughts on this idea. I am happy to create a PR along these lines, but wanted to write something up quickly that others may comment on:

• The primary use case where I miss a feature like this is to get the length of a header in bytes, in order to know how much to add or subtract from a field like IPv4 Total Length, or IPv6 Payload Length, which are in units of bytes. Therefore I think the minimum addition should be a way to get the length in bytes of a header with no varbit field. Without that capability, I don't see much motivation to make a change.

• Propose that whenever possible, these new operations return compile time constants, to enable compiler optimization of expressions involving multiple such values, e.g. adding up several header lengths, as shown in the example code of the first comment in this issue.

• If a fixed length header is not a multiple of 8 bits long (which is allowed in P4_16 language spec, even though implementations may make that restriction, and several do), I would propose that the operation used to get the length of the header in bytes returns the minimum number of bytes required to hold that number of bits, e.g. if the length in bits is B, then the 'how many bytes long this header is' operation returns floor((B+7)/8).

• Since P4_16 allows implementations to have headers that are not multiples of 8 bits long, it seems like it may be reasonable to suggest that there be a separate operation that returns a header's length in bits. This is a weakly offered suggestion more for completeness sake, rather than an operation that I know has some strong use case. We could leave it out now and consider adding such a thing later, too.

• Propose that this operation be valid on a single element of a header stack, too, and return the length in bytes of that one element of the header stack. Also that it be useful on an entire header stack, and return the total length of all elements of the header stack.

• Propose that this operation be valid on a header_union, too, and in that case that it returns the maximum length among all elements of the header_union.

• For headers with a varbit field in them, an operation that returns a compile time constant has only two reasonable options that I can think of: use 0 as the length of the varbit field, or use the varbit field's maximum length. I would propose the maximum length as the more useful of the two.

• Does anyone have interest as implementers in supporting an operation that returns the current run-time variable length of a varbit field? That could be a separate issue from this one, if it runs into hurdles. It is also something that is possible for a P4 programmer to use metadata to keep track of, since the varbit's length is known during parsing time. I for one am happy to not include such a thing while resolving this issue.

• Propose that this operation is not supported on any other type of object, e.g. it is not supported on structs. Why? Because I think it will lead to interminable arguments about the meaning of such an operation, and I don't see a strong use case for it.

• Syntax! I dont' have strong opinions here, and am open to compiler writer's suggestions, e.g. especially if there is syntax that makes it easier for the compiler to treat the return value as a compile time constant.

Some possibilities for syntax:

• sizeof(hdr_variable)
• hdr_variable.size
• hdr_variable.size()

If we support the ability to have a separate operation get the size in bits, I would propose including "bits" somewhere in its name, to distinguish it from the one that returns bytes. We could also explicitly include "bytes" in the names of the operation that return bytes.

[mihaibudiu]

This looks very reasonable.
How about querying a type, and not a variable?

[jafingerhut]

I have no problem with querying a type. I suspect the choice of syntax might matter more for that case than for querying a variable. Any suggestions on what syntax choices would work well for either a variable or a type, vs. which would not work well for a type?

[mihaibudiu]

I like the dot syntax best, because it does not polute the namespace of global identifiers.
Maybe we can add methods on types too...
type.size()

[mihaibudiu]

We should check that the grammar is not ambiguous then.

[jnfoster]

I'm not strongly opposed, but why query the type rather than the instance? We have no other methods on types. I guess I don't see a reason to invent that category of operation unless there is a deep reason to do so....

[jafingerhut]

For the primary use case as demonstrated in the first comment of this issue, only allowing this new operation on variables, and not on types, will do the job perfectly.

I could imagine someone maybe wanting to know the length of a header that was neither parsed, nor is ever valid in an output packet, but that seems much much rarer to me. Even then, if we only supported the new operation on variables, the simple workaround is to require the P4 programmer to create one instance of that type, only for the purpose of getting its size.

[jnfoster]

I suppose the familiarity with C's sizeof is another potential reason... although I personally find that borrowing features that work similarly to but not quite exactly the same as in another language is a recipe for confusion.

[jafingerhut]

I am not married to any particular name, including sizeof. If a we think a name other than sizeof would avoid confusion, cool.

[mihaibudiu]

Actually using the syntax .size is a problem if the structure has a field named size...