[P4-design] Transit Tags and Egress Processing

Peter Newman (petenewm) petenewm at cisco.com
Tue Aug 4 17:30:15 EDT 2015

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/20150804/8f73166e/attachment-0001.html>

More information about the P4-design mailing list