[P4-design] Transit Tags and Egress Processing

Haoyu song haoyu.song at huawei.com
Tue Aug 4 22:34:39 EDT 2015

Good point. But I'm not sure P4 program should care how the transit tag (we call it frame header) is formatted since this is heavily target dependent.  In our implementation, the compiler does need to analyze the program to learn what info needs to be transited form ingress to egress and then encode and pack the info in to a frame header. The egress will need to use offset and length to retrieve the info, but this is transparent to P4 program.  This leads to my first proposal: If for each packet, its egress control flow can be designated, it will help the compiler to make the most efficient frame header encoding. This is because for each egress control flow, only a part of metadata is needed and the frame header can be overloaded.

Now I'm thinking to separate the ingress control flow too. This can be done easily because each parse tree branch can return to a different control flow. In this case, for each service, we will naturally have a pair of ingress and egress control flows. There are some common control flows that can be included by the service control flow as modules.

In the second "direct" table proposal I made yesterday, the modification is very simple. For tables that can be implemented as a direct table, in the table "reads" fields, just replace the key word "exact" with "direct". The following example is from P4 "switch" demo. Apparently, here the nexthop_index is just a index to a direct table. It's unnecessary and inefficient to implement it with a hash table. If we don't explicitly make it a direct table, the compiler won't be able to figure out this optimization opportunity.

[cid:image003.jpg at 01D0CEEC.9B4776A0]

I'll gather more information to support the necessity of embedded parsing. This can be done by either adding new primitives or reusing the current Parser structure but in a distributed way.


From: P4-design [mailto:p4-design-bounces at p4.org] On Behalf Of Peter Newman (petenewm)
Sent: Tuesday, August 04, 2015 2:30 PM
To: p4-design at p4.org
Subject: [P4-design] Transit Tags and Egress Processing

The discussion at yesterday's meeting surrounding the presentation by Huawei got me thinking.

In most every switch I remember working on we add a tag to each packet at the ingress. It used to be that the tag was used to direct the packet across the backplane or the switch fabric to the required egress. These days the required egress is just as likely to be in the far corner of the same piece of silicon. However, in all cases, the egress is far enough removed from the ingress that it cannot share the parsed representation of the packet that was created during ingress processing.

It is likely that a large class of switch designs will want to avoid completely re-parsing the packet at the egress. To avoid re-parsing the packet it may be sufficient to expand the transit tag and have the ingress add a few pointers, indexes and flags sufficient for the egress to do its job. If so, at the egress, all we have to work with are the fields of the transit tag and an opaque packet header. I begin to see the justification for wanting to be able to specify table operations in terms of widths and offsets at least at the egress.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150805/6a3c807f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 4982 bytes
Desc: image003.jpg
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150805/6a3c807f/attachment.jpg>

More information about the P4-design mailing list