Design principles for packet parsers

Gibb, Glen; Varghese, George; Horowitz, Mark; McKeown, Nick

doi:10.1109/ancs.2013.6665172

Cited by 83 publications

(83 citation statements)

References 11 publications

(13 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…SRAM densities are now around 7000 Kb /mm 2 [13]. The smallest switching chips occupy 200 mm 2 [20]. Relative to these chips, a 32-Mbit cache in SRAM costs under 2.5% additional area, which we believe is reasonable.…”

Section: Evaluation Of Hardware Designmentioning

confidence: 88%

“…These are already leveraged by applications like In-band Network Telemetry [6]. The set of packet headers in the schema-including standard headers, metadata and userdefined ones-can be parsed by a programmable switch parser [20]. The SELECT ... WHERE clause can be realized using a programmable match-action switch pipeline [17] that allows matches and actions on all parsable headers; on such pipelines, we can implement the WHERE predicate as the match condition.…”

Section: Using Emerging Programmable Switchesmentioning

confidence: 99%

“…We find that performance queries are feasible using a 32-Mbit SRAM cache, and a backing store that can support~802K cache evictions per second. These requirements can be easily met: a 32-Mbit SRAM cache occupies < 2.5% of the die area of a switching chip [20]), while scale-out key-value stores such as Memcached and Redis support a few hundred thousand operations per second per core [5,24,10, 1].…”

Section: Introductionmentioning

confidence: 99%

“…The recent emergence of programmable switching chips [2,15,7] suggests a change in thinking. Currently, however, these chips only support flexible packet parsing [20] and header processing [17]; their hardware primitives for measurement are still limited. Ideally, these chips would offer similar flexibility for network measurement as well.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Hardware-Software Co-Design for Network Performance Measurement

Narayana

Sivaraman

Nathan

et al. 2016

Proceedings of the 15th ACM Workshop on Hot Topics in Networks

View full text Add to dashboard Cite

Diagnosing performance problems in networks is important, for example to determine where packets experience high latency. However, existing diagnostic tools are constrained by limited switch mechanisms for measurement. As a result, operators use endpoint information to indirectly infer root causes for performance issues.Instead of designing piecemeal solutions to work around limited switch mechanisms, we believe that the right approach is to co-design language abstractions and switch hardware primitives for performance measurement. This approach provides confidence that the switch primitives are useful for a variety of existing and unanticipated use cases.We present a declarative query language that allows operators to ask a diverse set of network performance questions. We show that these queries can be implemented efficiently in switch hardware using a programmable key-value store primitive. Our preliminary evaluations show that our hardware design incurs modest additional chip area relative to existing switching chips, suggesting that it is a practical solution for network performance measurement.

show abstract

Section: Evaluation Of Hardware Designmentioning

confidence: 88%

Section: Using Emerging Programmable Switchesmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Hardware-Software Co-Design for Network Performance Measurement

Narayana

Sivaraman

Nathan

et al. 2016

Proceedings of the 15th ACM Workshop on Hot Topics in Networks

View full text Add to dashboard Cite

show abstract

“…Next, because no existing programmable switch supports the set of atoms required for our data-plane algorithms, we design a set of compiler targets for these algorithms based on Banzai ( §5.2). We show that these targets are feasible in a 32-nm standard-cell library with < 2% cost in area relative to a 200 mm 2 baseline switching chip [40]. Finally, we compile data-plane algorithms written in Domino to these targets ( §5.3) to show how a target's atoms determine the algorithms it can support.…”

Section: Introductionmentioning

confidence: 99%

Packet Transactions

Sivaraman¹,

Cheung

Budiu

et al. 2016

Proceedings of the 2016 ACM SIGCOMM Conference

Self Cite

208

View full text Add to dashboard Cite

Many algorithms for congestion control, scheduling, network measurement, active queue management, and traffic engineering require custom processing of packets in the data plane of a network switch. To run at line rate, these dataplane algorithms must be implemented in hardware. With today's switch hardware, algorithms cannot be changed, nor new algorithms installed, after a switch has been built. This paper shows how to program data-plane algorithms in a high-level language and compile those programs into low-level microcode that can run on emerging programmable line-rate switching chips. The key challenge is that many data-plane algorithms create and modify algorithmic state. To achieve line-rate programmability for stateful algorithms, we introduce the notion of a packet transaction: a sequential packet-processing code block that is atomic and isolated from other such code blocks.We have developed this idea in Domino, a C-like imperative language to express data-plane algorithms. We show with many examples that Domino provides a convenient way to express sophisticated data-plane algorithms, and show that these algorithms can be run at line rate with modest estimated chip-area overhead.

show abstract

Smashing OpenFlow's “atomic” actions: Programmable data plane packet manipulation in hardware

2018

View full text Add to dashboard Cite

Summary Recently, with new hardware architectures such as Reconfigurable Match Tables and languages such as P4, the Software Defined Networking community has started to bring line‐rate data plane programmability inside switching chipsets. Starting from the original OpenFlow's match/action abstraction, most of the work has so far focused on key improvements in matching flexibility. Conversely, the “action part,” ie, the set of operations (such as encapsulation or header manipulation) performed on packets after the forwarding decision, has received way less attention. Goal of this paper is to move beyond the idea of “atomic,” preimplemented, actions, and rather make them programmable while retaining high speed multi‐Gbps operation. To this purpose, we propose a domain‐specific HW architecture, called Packet Manipulation Processor (PMP), able to efficiently implement such actions. Both a PMP C++ instruction set simulator and a NetFPGA prototype have been developed. The performances of the PMP have been verified with three nontrivial use cases (tunneling, NAT, and ARP reply generation), showing that also in the worst case the throughput is well above 10 Gbps.

show abstract

Design principles for packet parsers

Cited by 83 publications

References 11 publications

Hardware-Software Co-Design for Network Performance Measurement

Hardware-Software Co-Design for Network Performance Measurement

Packet Transactions

Smashing OpenFlow's “atomic” actions: Programmable data plane packet manipulation in hardware

Contact Info

Product

Resources

About