Modeling TCAM-Based Packet Parsers
Programmable networking hardware (e.g. switches, SmartNICs, etc) is manufactured by a variety of vendors, using proprietary designs. Designers tend to use similar high-level principles, but make different implementation decisions. This has several negative consequences:
- It is difficult to predict if a given piece of hardware can support a particular program.
- Manufacturers face a huge design burden when creating new hardware.
- Compilers must be implemented from scratch for each piece of hardware.
To combat this problem, we have created a high-level, abstract model of the most common packet-processing architecture: a series of TCAMs. Our design is inspired by prior work by Glen Gibb et. al., but can be configured to represent the various implementation details of particular hardware, such as the width of TCAM rules and the ability to read and write memory during parsing. We are currently developing a compiler for compiling P4 parsers to programs for our model, and have developed an interpreter for simulating those programs for validation purposes.
This talk will discuss our model, configuration language, intermediate representation, and discuss our ongoing implementation of our P4 compiler. We intend to open-source all parts of this project, so our model and tooling can be re-used by hardware manufacturers and the greater P4 community.
Good presentation, thanks.
CAIRN needs an external step to remove parser loops. The Kangaroo parser, a static parser, removes loops.
A mix of packets will produce variable parsing performance with multiple TCAM stages in CAIRN. The Kangaroo parser uses one TCAM layer and uses SRAM for slower parsing. So, Kangaroo has constant performance.
Hemant
--
You received this message because you are subscribed to the Google Groups "p4-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to p4-dev+un...@lists.p4.org.
To view this discussion on the web visit https://groups.google.com/a/lists.p4.org/d/msgid/p4-dev/CAKvLtDaW_VMdF%2BffLdbT3A9SmxEUMORttWqhyAJ0yTH8Qe2G_Q%40mail.gmail.com.
There’s no reason why parsing performance can’t be constant with multiple TCAM stages. If all packets go through all stages, then performance should be constant. (The key can be set to a value that will never match once parsing is done for a packet.)
Glen
To view this discussion on the web visit https://groups.google.com/a/lists.p4.org/d/msgid/p4-dev/038d01d9cfc5%242ce125c0%2486a37140%24%40mnkcg.com.
Of course, if all packets go through all stages. But a MPLS packet can use only one stage and a srv6 packet uses many stages.
An orthogonal issue is that a CAIRN parser that uses only TCAM is not practical in a production node because TCAM is very expensive. Production nodes use TCAM and SRAM to save cost.
Hemant
TCAM-based parsers along the lines of the CAIRN model have been used in production systems. Mike Davies from Fulcrum Microsystems described some of their silicon at Hot Chips in 2011 [1, 2]. Their parser (slides 12-15 in [2]) resembles the CAIRN model. And there are products on the market today with parsers that resemble this design.
A CAIRN-style parser is not appropriate for every application, but I think it is a design choice that provides high flexibility, relative ease of programmability (all stages are the same/there’s no difference in configuration for common vs uncommon packet types), high throughput, and deterministic performance, while possibly consuming more power and area than some other design choices.
[1] https://ieeexplore.ieee.org/document/7477502
Glen
To view this discussion on the web visit https://groups.google.com/a/lists.p4.org/d/msgid/p4-dev/03e701d9cfd8%2436185470%24a248fd50%24%40mnkcg.com.