[P4-dev] where to add_header?

Antonin Bas antonin at barefootnetworks.com
Sun Sep 25 16:40:55 EDT 2016


This P4 program was meant as a simple example and assumes that the packets
received never include the cpu_header.
If you want to be able to parse the cpu_header properly when it is present,
and assuming you still want the cpu_header to come *before* the ethernet
header, then I suggest something like this:
header_type cpu_header_t {
    fields {
        preamble: 64;
        device: 8;
        reason: 8;
     }
}
now I have added a 8-byte preamble to my cpu header, and I require it to be
all 0s.
The parser code should remain the same. Don't forget to set the preamble to
0 when adding the cpu_header.
Now if a packet actually starts with 8 bytes of 0s then it means it starts
with a cpu_header and the cpu_header will be extracted, which means that
the ethernet header will be extracted correctly no matter what.

If you need the cpu_header to come *after* the ethernet header, then I
suggest you introduce a new ethertype value for your cpu_header.

On Sun, Sep 25, 2016 at 1:33 PM, Yuliang Li <yuliangl at usc.edu> wrote:

> Thank you Antonin. This is very clear.
>
> I have a follow up question. Suppose the original packet (without the cpu
> header) is p, and after p is added the cpu header becomes p'. When the p'
> arrives at the next hop, the current(0,64)==0 is still false, but the cpu
> header is in the p'. So the parser start will mistakenly parse the ethernet
> on the bits of the cpu header. How do you solve this? Or the next hop uses
> a different p4 code?
>
> Thanks,
> Yuliang
>
> On Sun, Sep 25, 2016 at 4:21 PM, Antonin Bas <antonin at barefootnetworks.com
> > wrote:
>
>> Hi,
>>
>> In this simple example, we assume that we do not receive packets with the
>> cpu_header. However, we need the cpu_header to appear in the parse graph,
>> otherwise the deparser will not know where to insert it in an outgoing
>> packet. The cpu_header needs to come right before the ethernet header in
>> the topological sorting. Therefore we need to make sure that in the parse
>> graph there exists a ethernet->cpu_header transition. This is why we have
>> the following parse state:
>> parser parse_cpu_header {
>>     extract(cpu_header);
>>     return parse_ethernet;
>> }
>> If we do not reference this parse state anywhere, it will be removed by
>> the compiler (unused object). Therefore, we add a *dummy transition*
>> from the start state to parse_cpu_header. This is why we use current(0,
>> 64)==0 for our transition. We assume that regular ethernet packets won't
>> start with 8 bytes of 0s and that this transition will never be used.
>> However, because there exists a transition, the compiler will not remove
>> our parse state.
>>
>> More generally, if you have two headers A and B. For incoming packets A
>> is always followed immediately by B. In our pipeline, we sometimes add a
>> third header C. C will never appear in an incoming packet. However, we want
>> the deparser to be able to emit C, right between A and B. Then we need to
>> use the following P4 code:
>> parser parse_A {
>>     extract(A);
>>     return select(*x*) {
>>         *y*: parse_C;  // dummy transition (make sure *y* is not a valid
>> value for *x*)
>>         default: parse_B:
>> }
>> parser parse_B {
>>     extract(B);
>>     // ...
>> }
>> parser parse_C  {
>>     extract(C);
>>     return parse_B;
>> }
>>
>> In the next P4 version (P4-16), this "hack" won't be needed any more as
>> the language will offer a way to explicitly define deparser code.
>>
>> Thanks,
>>
>> Antonin
>>
>> On Sun, Sep 25, 2016 at 11:40 AM, Yuliang Li <yuliangl at usc.edu> wrote:
>>
>>> Thank you Antonin.
>>>
>>> I have a question regarding the copy to cpu example. In the parser
>>> start, it uses current(0,64)==0 to decide if parse the CPU header or not,
>>> but the CPU header only has16 bits. So I am a bit confused.
>>>
>>> On Sat, Sep 24, 2016 at 7:38 PM, Antonin Bas <
>>> antonin at barefootnetworks.com> wrote:
>>>
>>>> Hi Yuliang,
>>>>
>>>> Your header has to be part of the parse graph. From the parse graph, we
>>>> compute a topological sorting which determines in which order the headers
>>>> are emitted when the packet is deparsed.
>>>> There is one example on p4lang of a P4 program which adds a CPU header
>>>> to packets: https://github.com/p4lang/tuto
>>>> rials/tree/master/examples/copy_to_cpu
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_p4lang_tutorials_tree_master_examples_copy-5Fto-5Fcpu&d=DQMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=-sjq3J2b6bOdupF1bsRuzQ&m=hVPplGkytizsR3NIsQ8BCRg2pRnf0nNOY4WEMIiBdDI&s=__hem8X-_ofBe4kKAJS8fA4Oy6ejfycH8JCaVtIXYuc&e=>
>>>> There are a few threads on this mailing list which talk about this in
>>>> more details. I would recommend looking at this one:
>>>> http://lists.p4.org/pipermail/p4-dev_lists.p4.org/2016-May/000319.html
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.p4.org_pipermail_p4-2Ddev-5Flists.p4.org_2016-2DMay_000319.html&d=DQMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=-sjq3J2b6bOdupF1bsRuzQ&m=hVPplGkytizsR3NIsQ8BCRg2pRnf0nNOY4WEMIiBdDI&s=Tz7wFzp_ppqkl3kdcFIQfIUunIebmZj15Tze6iAX8wI&e=>
>>>>
>>>> Thanks,
>>>>
>>>> Antonin
>>>>
>>>> On Sat, Sep 24, 2016 at 4:22 PM, Yuliang Li <yuliangl at usc.edu> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I want to add a header to each packet. I see there is a add_header
>>>>> API. But how do I indicate where to add the header (e.g. after TCP header).
>>>>>
>>>>> Thanks,
>>>>> Yuliang
>>>>>
>>>>> _______________________________________________
>>>>> P4-dev mailing list
>>>>> P4-dev at lists.p4.org
>>>>> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.p4.org_mailman_listinfo_p4-2Ddev-5Flists.p4.org&d=DQMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=-sjq3J2b6bOdupF1bsRuzQ&m=hVPplGkytizsR3NIsQ8BCRg2pRnf0nNOY4WEMIiBdDI&s=mAMbIbM0dOLPeD5OVocPsNV1-Gp7YPWw3OyL_-ds2CY&e=>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Antonin
>>>>
>>>
>>>
>>
>>
>> --
>> Antonin
>>
>
>


-- 
Antonin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20160925/8b7ce050/attachment-0002.html>


More information about the P4-dev mailing list