[P4-design] Transit Tags and Egress Processing
Peter Newman (petenewm)
petenewm at cisco.com
Thu Aug 6 15:23:53 EDT 2015
I read up on Protocol-oblivious Forwarding this morning. It fills in some of the back-story to the debate. I’d like to step back from that debate to focus only on whether I need to implement a full programmable parser on the egress.
If I were implementing a fixed function forwarding engine I might choose not to implement a packet parser on the egress but manage with an internal transit tag with some flags, pointers and indexes set by the ingress. It’s a simple bandwidth versus silicon area trade-off.
In a programmable forwarding engine I might still choose to go the transit tag route. In this case I would still want to program the egress functionality in P4. It would be up to the back-end of the compiler to figure out how to implement the P4 program without recourse to a packet parser. I can imagine the back-end of the compiler being able to do this without needing any <offset, width> instructions in P4 as long as it can define the fields required in the transit tag.
So how do I communicate this back to the programmer? Does the back-end of the compiler specify and add the transit tag automatically without informing the programmer? Would the programmer wish to add anything to this tag if they knew it was there? How do I express this in the architecture specification for the hardware?
Haoyu, I think you are way ahead of me. I don’t know whether it would help the compiler if the egress control flow were designated for each packet. I’ll need to look at your proposal again. I agree that you may want to use an efficient encoding with transit tag content depending upon an opcode.
On Aug 4, 2015, at 7:34 PM, Haoyu song <haoyu.song at huawei.com<mailto:haoyu.song at huawei.com>> wrote:
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.
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<mailto: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...
More information about the P4-design