[P4-dev] P4 variable fields

shubham bhardwaj bhardwajshubham2011 at gmail.com
Wed Jul 26 18:44:32 EDT 2017


Yes, I have three other fields after that variable field that I want to
parse. That's why I am trying to calculate the length.

On Wed, 26 Jul 2017 at 10:24 PM, Andy Fingerhut <andy.fingerhut at gmail.com>
wrote:

> Probably most P4 implementations provide a packet_length of the received
> packet and make it available in the ingress control block.  A notable
> exception would be any device that does cut-through forwarding, i.e.
> starting running the P4 code on the packet header before the entire packet
> has arrived into the device, where it is not possible to know the
> packet_length.
>
> In some experiments recently I have learned that the open source
> simple_switch process that is part of the
> https://github.com/p4lang/behavioral-model project makes a packet_length
> available on ingress as part of the standard_metadata_t struct, and it
> appears to always be the number of bytes in the Ethernet header plus
> Ethernet payload, not counting any Ethernet CRC at the end, and it can be
> smaller than 64 bytes, so it does not include any padding in the Ethernet
> payload required to meet the minimum Ethernet frame size requirements.
>
> If you had a packet_length like that available for your purposes, do you
> know how you would calculate the length of the variable-length field of
> interest to you in the Profinet protocol?
>
> If the answer is: from the end of this header, I always want the rest of
> the packet from that point forward, until the end of the packet, then that
> is exactly what in P4 is considered the 'payload', if you don't parse it,
> and by default gets copied after any headers you emit in your deparser.
>
> If the answer is something _less_ than that, then perhaps calculating the
> length of the variable length header and extracting it might make sense for
> your application.
>
> Is the reason that you want to extract this variable-length header because
> there is more in the packet after it, and you want to parse and extract
> that part of the packet, too?  If that isn't the reason, then it isn't
> clear to me what benefit you are hoping to get by extracting this
> variable-length header.
>
> Andy
>
> On Wed, Jul 26, 2017 at 3:09 AM, shubham bhardwaj <
> bhardwajshubham2011 at gmail.com> wrote:
>
>> I am not sure, but can't we derive the packet length from the metadata. I
>> mean if there is no packet length field in a header itself, then it should
>> be somewhere and the metadata is my best guess.
>>
>> On Sun, Jul 23, 2017 at 10:43 PM, Andy Fingerhut <
>> andy.fingerhut at gmail.com> wrote:
>>
>>> Can you describe how software written in some language other than P4
>>> determines the length of this variable-length part of the packet?  I am not
>>> familiar with this Profinet protocol, and don't have any interest in
>>> spending significant time learning about it, but if you can precisely
>>> describe one way to determine the field's length, maybe someone will think
>>> of a way that a P4 program might be able to do it, too.
>>>
>>> Andy
>>>
>>> On Sun, Jul 23, 2017 at 10:36 AM, shubham bhardwaj <
>>> bhardwajshubham2011 at gmail.com> wrote:
>>>
>>>> Hello Andy,
>>>>
>>>> Thanks for your reply, but the header I am trying to parse is not the
>>>> payload (rest of the packet) and the only field before it is FrameID which
>>>> is providing information about the type of data, for example, RTC1, RTC2,
>>>> RTC3, etc. Therefore, I am not sure how I can calculate the variable field
>>>> length from this field.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.
>>>> www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>>> <#m_-5020793771600839367_m_-2431767368020277807_m_-1614252644282559178_m_4901917783758041970_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>
>>>> On Sat, Jul 22, 2017 at 8:03 PM, Andy Fingerhut <
>>>> andy.fingerhut at gmail.com> wrote:
>>>>
>>>>> The only way that P4 programs can extract a variable-length field from
>>>>> a packet is if there is some field in the packet before that
>>>>> variable-length field, from which the length of the variable-length field
>>>>> can be calculated.
>>>>>
>>>>> If the variable-length field you want is "the rest of the packet, all
>>>>> the way to the end", I don't see any advantage to extract'ing it -- any
>>>>> header you do not extract in P4 is considered part of the payload,
>>>>> automatically, and the payload will automatically be copied from the
>>>>> received packet to the transmitted packet, after the headers your program
>>>>> emit's.
>>>>>
>>>>> Andy
>>>>>
>>>>> On Fri, Jul 21, 2017 at 5:33 AM, shubham bhardwaj <
>>>>> bhardwajshubham2011 at gmail.com> wrote:
>>>>>
>>>>>> Adding on, this length can go up to 40 - 1440 but my main question is
>>>>>> if there is no header length field is present in the header. Then, is there
>>>>>> any way to form an expression for the variable length. For example, in the
>>>>>> above case there is no header field in Ethernet and its payload i.e.
>>>>>> Profinet.
>>>>>>
>>>>>> Thanks & Regards
>>>>>>
>>>>>> On Wed, Jul 19, 2017 at 10:10 PM, shubham bhardwaj <
>>>>>> bhardwajshubham2011 at gmail.com> wrote:
>>>>>>
>>>>>>> Yeah, this is wrong. I found out that the length should be the
>>>>>>> (packet length - fixed fields length). Right now the packet i am parsing is
>>>>>>> of 46 bytes and fixed fields are of 6 bytes. I am not sure that the fields
>>>>>>> in this header contain any details about the header length (like IHL in
>>>>>>> IPv4). This is the screenshot of the packet, header fields, and the parsed
>>>>>>> output. I am using length as 40 bytes (which is probably wrong) and also i
>>>>>>> am not getting any result for the variable field from this value.
>>>>>>>
>>>>>>> [image: Inline image 1]
>>>>>>>
>>>>>>> fields {
>>>>>>> frameID: 16;
>>>>>>>         cyclecounter: 16;
>>>>>>> datastatus: 8;
>>>>>>> transferstatus: 8;
>>>>>>>         profinetcyclic: *;
>>>>>>>        }
>>>>>>> length: 40;
>>>>>>> max_length: 80;
>>>>>>> }
>>>>>>>
>>>>>>> [image: Inline image 2]
>>>>>>>
>>>>>>> On Wed, Jul 19, 2017 at 6:31 PM, Andy Fingerhut <
>>>>>>> andy.fingerhut at gmail.com> wrote:
>>>>>>>
>>>>>>>> The length expression 'frameID * 20' can be much larger than 512,
>>>>>>>> since frameID is 16 bits in size.  I don't know if that is causing any
>>>>>>>> issues for you.
>>>>>>>>
>>>>>>>> What is going wrong when you try to compile/run the program you
>>>>>>>> shared?
>>>>>>>>
>>>>>>>> Andy
>>>>>>>>
>>>>>>>> On Wed, Jul 19, 2017 at 6:05 AM, shubham bhardwaj <
>>>>>>>> bhardwajshubham2011 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello Andy,
>>>>>>>>>
>>>>>>>>> Thanks for your reply, its really helpful. But i am facing another
>>>>>>>>> issue in initializing the variable length. I am able to initialize variable
>>>>>>>>> length of the field options for IPv4, as already explained by Antonin.
>>>>>>>>> However, I am not able to do the same for Profinet RT header, which is a
>>>>>>>>> low-level protocol. I am not sure if i am doing something wrong or is there
>>>>>>>>> any other issue.
>>>>>>>>>
>>>>>>>>> //Ethernet header
>>>>>>>>> header_type ethernet_t {
>>>>>>>>>     fields {
>>>>>>>>>         dstAddr: 48;
>>>>>>>>>         srcAddr: 48;
>>>>>>>>>         etherType: 16;
>>>>>>>>>      }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> //Profinet header
>>>>>>>>> header_type Profinet_RT_t {
>>>>>>>>>     fields {
>>>>>>>>> frameID: 16;
>>>>>>>>>         profinetcyclic: *;
>>>>>>>>>    }
>>>>>>>>> length: frameID * 20;
>>>>>>>>> max_length: 512;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jul 18, 2017 at 4:57 PM, Andy Fingerhut <
>>>>>>>>> andy.fingerhut at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> The only ways I know of in P4 programs to fill in the values of
>>>>>>>>>> variable-length fields of headers is to extract() them from a packet being
>>>>>>>>>> parsed.  From there, they can be copied (without any modifications) to
>>>>>>>>>> other instances of the same type of header, by copy_header() in P4_14, or
>>>>>>>>>> in P4_16 simply assigning the value of one header to another of the same
>>>>>>>>>> type.
>>>>>>>>>>
>>>>>>>>>> I believe it would be nice if P4_16 were extended to include ways
>>>>>>>>>> to copy parts of varbit fields and copy them into fixed-width
>>>>>>>>>> fields/variables, or vice versa, and I have suggested such a language
>>>>>>>>>> addition on this Github issue:
>>>>>>>>>> https://github.com/p4lang/p4-spec/issues/264   It will probably
>>>>>>>>>> be some time before significant-sized changes will be made to the P4_16
>>>>>>>>>> spec, and there is no consensus yet on whether such a change is of interest
>>>>>>>>>> to a wider audience.
>>>>>>>>>>
>>>>>>>>>> Andy
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 18, 2017 at 6:07 AM, shubham bhardwaj <
>>>>>>>>>> bhardwajshubham2011 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Dear All,
>>>>>>>>>>>
>>>>>>>>>>> I am working on a case where a single field in a header can vary
>>>>>>>>>>> in length. In that case, is it possible to initialize it using variable
>>>>>>>>>>> fields.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Thanks & Regards
>>>>>>>>>>> Shubham Bhardwaj
>>>>>>>>>>> *Technical University of Darmstadt*
>>>>>>>>>>> +49 17643686394 <+49%20176%2043686394>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> P4-dev mailing list
>>>>>>>>>>> P4-dev at lists.p4.org
>>>>>>>>>>> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks & Regards
>>>>>>>>> Shubham Bhardwaj
>>>>>>>>> *Technical University of Darmstadt*
>>>>>>>>> +49 17643686394 <+49%20176%2043686394>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks & Regards
>>>>>>> Shubham Bhardwaj
>>>>>>> *Technical University of Darmstadt*
>>>>>>> +49 17643686394 <+49%20176%2043686394>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks & Regards
>>>>>> Shubham Bhardwaj
>>>>>> *Technical University of Darmstadt*
>>>>>> +49 17643686394 <+49%20176%2043686394>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks & Regards
>>>> Shubham Bhardwaj
>>>> *Technical University of Darmstadt*
>>>> +49 17643686394 <+49%20176%2043686394>
>>>>
>>>
>>>
>>
>>
>> --
>> Thanks & Regards
>> Shubham Bhardwaj
>> *Technical University of Darmstadt*
>> +49 17643686394 <+49%20176%2043686394>
>>
>
> --
Thanks & Regards
Shubham Bhardwaj
*Technical University of Darmstadt*
+49 17643686394
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170726/fe958229/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12505 bytes
Desc: not available
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170726/fe958229/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 39008 bytes
Desc: not available
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170726/fe958229/attachment-0001.png>


More information about the P4-dev mailing list