DOCSLIB.ORG

High Level Synthesis for Packet Processing Pipelines Cristian

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
High Level Synthesis for Packet Processing Pipelines Cristian High Level Synthesis for Packet Processing Pipelines Cristian Soviani Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2007 c 2007 Cristian Soviani All Rights Reserved ABSTRACT High Level Synthesis for Packet Processing Pipelines Cristian Soviani Packet processing is an essential function of state-of-the-art network routers and switches. Implementing packet processors in pipelined architectures is a well-known, established technique, albeit different approaches have been proposed. The design of packet processing pipelines is a delicate trade-off between the desire for abstract specifications, short development time, and design maintainability on one hand and very aggressive performance requirements on the other. This thesis proposes a coherent design flow for packet processing pipelines. Like the design process itself, I start by introducing a novel domain-specific language that provides a high-level specification of the pipeline. Next, I address synthesizing this model and calculating its worst-case throughput. Finally, I address some specific circuit optimization issues. I claim, based on experimental results, that my proposed technique can dramat- ically improve the design process of these pipelines, while the resulting performance matches the expectations of hand-crafted design. The considered pipelines exhibit a pseudo-linear topology, which can be too re- strictive in the general case. However, especially due to its high performance, such an architecture may be suitable for applications outside packet processing, in which case some of my proposed techniques could be easily adapted. Since I ran my experiments on FPGAs, this work has an inherent bias towards that technology; however, most results are technology-independent. Contents 1 Introduction 1 1.1 PacketprocessinginsideaSwitch . 1 1.1.1 FPGAparticularities . 4 1.2 Packetprocessingpipelines. 6 1.3 Packeteditingmodules.......................... 7 1.4 Mainchallenges.............................. 8 1.5 Challenge: Avoiding RTL . 9 1.5.1 Contribution: high level packet editor description . ..... 10 1.5.2 Contribution: packet editor synthesis . 11 1.6 Challenge: Pipeline worst case performance . 12 1.6.1 Contribution: pipeline performance analysis . 14 1.6.2 Computing minimum FIFO sizes . 15 1.7 Challenge: Sequential RTL issues . 15 1.7.1 Contribution: combining Retiming and Shannon . 17 1.8 Contributionsummary. Thesisoutline . 18 2 Synthesis of Packet Processing Pipelines 19 2.1 Overview.................................. 19 2.2 PacketProcessorsandEditing . 21 ii 2.3 Relatedwork ............................... 23 2.4 ThePacketEditingGraph . 23 2.4.1 WhattoexpectfromthePEG. 23 2.4.2 APEGExample ......................... 24 2.4.3 PEGdescription ......................... 26 2.4.3.1 Theinputsubgraph . 28 2.4.3.2 The computation subgraph . 29 2.4.3.3 Theoutputsubgraph. 30 2.5 TheSynthesisProcedure . 32 2.5.1 ThemoduleI/Oprotocol . 34 2.5.2 CoreandWrapper ........................ 36 2.5.3 SplittingDataintoWords . 37 2.5.4 Assigning Read Cycle Indices . 40 2.5.5 Scheduling............................. 42 2.5.6 Synthesizing the controller . 43 2.5.7 Handlingtheendofapacket. 45 2.5.8 Synthesizingthedatapath. 47 2.5.9 Comments on scheduling and binding . 48 2.5.10 Comments on FSM encoding .................. 50 2.6 Implementation .............................. 51 2.6.1 Textualfrontend ......................... 51 2.6.2 Synthesissteps .......................... 51 2.6.3 Simulation............................. 52 2.6.4 RTL and Low-Level Synthesis . 53 2.7 ExperimentalResults........................... 54 2.8 Conclusions ................................ 55 iii 3 Packet Processing Pipeline Analysis 56 3.1 Overview.................................. 56 3.1.1 Motivational example . 58 3.2 RelatedWork ............................... 59 3.3 Singlemoduleanalysis .......................... 61 3.3.1 Definingmoduleperformance . 62 3.3.2 Computing R,W , and T fromtheSTG ............. 63 3.3.3 UsingBellman-Ford. 66 3.3.4 Abstractingthedatapath . 68 3.4 Connectingmodules ........................... 69 3.4.1 ThemoduleI/Oprotocol . 70 3.4.2 The FIFO implementation . 72 3.5 TheBigFIFOscenario.......................... 73 3.5.1 Computingtheworst-casethroughput . 74 3.5.2 Performanceissues ........................ 75 3.5.3 Moduleindependence. 76 3.6 Verifying throughput using model checking . 76 3.6.1 Comparison with explicit analysis . 78 3.6.2 Comparison with simulation . 79 3.7 ComputingtheminimumFIFOsizes . 79 3.7.1 ComputingFIFOSizes . 80 3.7.2 FIFO size monotonicity . 80 3.7.3 An exact depth-first search algorithm . 81 3.7.4 A heuristic search algorithm . 83 3.8 ExperimentalResults........................... 84 3.9 Conclusions ................................ 86 iv 4 Combining Shannon and Retiming 87 4.1 Introduction................................ 87 4.1.1 Briefdescription ......................... 88 4.1.2 Anexample ............................ 89 4.1.3 Overview of the algorithm . 91 4.1.4 Relatedwork ........................... 92 4.2 TheFirstPhase: ComputingArrivalTimes . 93 4.2.1 Basics ............................... 93 4.2.2 Shannondecomposition . 95 4.2.3 Shannon decomposition as a kind of technology mapping . 97 4.2.4 Redundant encodings and arrival times . 98 4.2.5 My family of Shannon encodings . 99 4.2.6 Sets of feasible arrival times . 102 4.2.7 Pruning feasible arrival times . 105 4.2.8 Retiming.............................. 107 4.2.9 Using Bellman-Ford to compute arrival times . 107 4.2.10 Termination of Bellman-Ford and max-iterations ........ 111 4.3 The Second Phase: Resynthesizing the Circuit . 112 4.3.1 Cell families . 116 4.3.2 Cell selection . 117 4.3.3 Propagating required times . 118 4.4 Experiments................................ 119 4.4.1 Combinational circuits . 119 4.4.2 Sequential benchmarks . 120 4.4.3 Packet processing pipelines . 123 4.5 Conclusions ................................ 124 v 5 Final Conclusions 126 5.1 Claim ................................... 126 5.2 PEG—thehumanfactor ........................ 127 5.3 Synthesis — taking advantage of others . 128 5.4 Analysis—choosingwhattomeasure. 130 5.5 Logic synthesis — beyond BLIF . 130 5.6 Openissues ................................ 131 5.6.1 Synthesis - Design space exploration . 131 5.6.2 Analysis — Performance under-estimation . 132 5.6.3 Low level optimization — Experiments . 133 Bibliography 133 vi List of Figures 1.1 Genericswitcharchitecture. 1 1.2 A switch with detail of a packet processing pipeline. .... 3 2.1 Graphic peg specification for the mpls module ............ 25 2.2 Textual peg specification for the mpls module............. 27 2.3 A module I/O signals and its two components . 34 2.4 Splitinto64-bitwords .......................... 38 2.5 Structuringapacketmapintowords . 39 2.6 Read cycle indices and delay bubbles added . 41 2.7 ASM chart for the controller synthesized from Figure 2.6 . 44 3.1 A packet pipeline: how big should the fifosbe?............ 58 3.2 stgsfortheDwVLANprocmodule . 64 3.3 Sample stg ................................ 67 3.4 Original and simplified module fsm ................... 70 3.5 Handshaking between module and adjacent fifos........... 71 3.6 stg of a 3-place fifo ........................... 72 3.7 Computing R assuming optimally-sized fifos ............. 75 3.8 slightly modified pipeline for the model checker . 77 3.9 Data source fsms............................. 77 vii 3.10 An exact algorithm for computing minimum fifos........... 82 3.11 Greedy Search for minimum size fifos ................. 83 4.1 Anexample ................................ 90 4.2 My algorithm for restructuring a circuit S to achieve a period c . 91 4.3 My Bellman-Ford algorithm for computing feasible arrival times . 94 4.4 Shannon decomposition of f with respect to xk ............ 96 4.5 ThebasicShannon“celllibrary” . 96 4.6 Shannon decomposition through node replacement. 97 4.7 The Shannon transform as redundant encoding. 98 4.8 Encoding x, evaluating f(x, y, z), and decoding the output for the s0, s1, s2, and s3 codes............................. 100 4.9 Computing feasible arrival times for a node f ............. 102 4.10 Pruning the feasible arrival times from Figure 4.9. ....... 106 4.11 Iterations near the lowest c ........................ 110 4.12 Computing feasible arrival times for a circuit . 113 4.13 Restructuringacircuit . 114 4.14 Selecting cells for node h inFigure4.12. 115 4.15 Propagating required times from outputs to inputs . 118 4.16 The performance/area tradeoff obtained by my algorithm on a 128-bit ripplecarryadder............................. 120 viii List of Tables 2.1 Synthesis results for selected modules . 54 3.1 Modulestatistics ............................. 84 3.2 Experimentalresults ........................... 85 4.1 Experiments on ISCAS89 sequential benchmarks . 121 4.2 Experiments on packet processing pipelines . 124 ix Acknowledgements I thank my advisor prof. Stephen A. Edwards for his constant guidance and help during my entire graduate school. Not only was his liberal advice essential for my academic progress but he actively contributed to the research that led to this thesis. Doubtlessly, most of the material presented below as original work was published before at several academic venues; with no exception Stephen has co-authored these publications. But scarcely was Stephen’s help strictly academic: he is my friend. I thank Dr. Ilija Hadzic, my mentor during my two Bell Labs
Load more

Recommended publications
  • Packet Processing at Wire Speed Using Network Processors
    Packet processing at wire speed using Network processors Chethan Kumar and Hao Che University of Texas at Arlington {ckumar, hche}@cse.uta.edu Abstract 1 Introduction Recent developments in fiber optics and the new The modern day Internet has seen an explosive bandwidth hungry applications have put more stress growth of applications being used on it. As more and on the active components (switches, routers etc.,) of a more applications are being developed, there is an network. Optical fiber bandwidth is no longer a increase in the amount of load put on the internet. At constraint for increasing the network bandwidth. the same time the fiber optics bandwidth has However, the processing power of the network has not increased dramatically to meet the traffic demand, but scaled upto the increase in the fiber bandwidth. the present day routers have limited processing power Communication industry is looking forward for more to handle this profound demand increase. Hence the innovative ways of designing router1 architecture and networking and telecommunications industry is research is being conducted to develop a scalable, compelled to look for new solutions for improving flexible and cost-effective architecture for routers. A the performance and the processing power of the successful outcome of this effort is a specialized routers. processor called Network processor. Network processor provides performance at hardware speeds One of the industry’s solutions to the challenges while attaining the flexibility of software. Network posed by the increased demand for the processing processors from different vendors employ different power is programmable functional units grouped into architectures and the choice of a particular type of a processor called Application Specific Instruction network processor can affect the architecture of the Processor (ASIP) or Network processor (NP)2.
    [Show full text]
  • Packet Processing Execution Engine (PROX) - Performance Characterization for NFVI User Guide
    USER GUIDE Intel Corporation Packet pROcessing eXecution Engine (PROX) - Performance Characterization for NFVI User Guide Authors 1 Introduction Yury Kylulin Properly designed Network Functions Virtualization Infrastructure (NFVI) environments deliver high packet processing rates, which are also a required dependency for Luc Provoost onboarded network functions. NFVI testing methodology typically includes both Petar Torre functionality testing and performance characterization testing, to ensure that NFVI both exposes the correct APIs and is capable of packet processing. This document describes how to use open source software tools to automate peak traffic (also called saturation) throughput testing to characterize the performance of a containerized NFVI system. The text and examples in this document are intended for architects and testing engineers for Communications Service Providers (CSPs) and their vendors. This document describes tools used during development to evaluate whether or not a containerized NFVI can perform the required rates of packet processing within set packet drop rates and latency percentiles. This document is part of the Network Transformation Experience Kit, which is available at https://networkbuilders.intel.com/network-technologies/network-transformation-exp- kits. 1 User Guide | Packet pROcessing eXecution Engine (PROX) - Performance Characterization for NFVI Table of Contents 1 Introduction ................................................................................................................................................................................................................
    [Show full text]
  • Lightweight Internet Protocol Stack Ideal Choice for High-Performance HFT and Telecom Packet Processing Applications Lightweight Internet Protocol Stack
    GE Intelligent Platforms Lightweight Internet Protocol Stack Ideal Choice for High-Performance HFT and Telecom Packet Processing Applications Lightweight Internet Protocol Stack Introduction The number of devices connected to IP networks will be nearly three times as high as the global population in 2016. There will be nearly three networked devices per capita in 2016, up from over one networked device per capita in 2011. Driven in part by the increase in devices and the capabilities of those devices, IP traffic per capita will reach 15 gigabytes per capita in 2016, up from 4 gigabytes per capita in 2011 (Cisco VNI). Figure 1 shows the anticipated growth in IP traffic and networked devices. The IP traffic is increasing globally at the breath-taking pace. The rate at which these IP data packets needs to be processed to ensure not only their routing, security and delivery in the core of the network but also the identification and extraction of payload content for various end-user applications such as high frequency trading (HFT), has also increased. In order to support the demand of high-performance IP packet processing, users and developers are increasingly moving to a novel approach of combining PCI Express packet processing accelerator cards in a standalone network server to create an accelerated network server. The benefits of using such a hardware solu- tion are explained in the GE Intelligent Platforms white paper, Packet Processing in Telecommunications – A Case for the Accelerated Network Server. 80 2016 The number of networked devices
    [Show full text]
  • Evaluating the Power of Flexible Packet Processing for Network Resource Allocation Naveen Kr
    Evaluating the Power of Flexible Packet Processing for Network Resource Allocation Naveen Kr. Sharma, Antoine Kaufmann, and Thomas Anderson, University of Washington; Changhoon Kim, Barefoot Networks; Arvind Krishnamurthy, University of Washington; Jacob Nelson, Microsoft Research; Simon Peter, The University of Texas at Austin https://www.usenix.org/conference/nsdi17/technical-sessions/presentation/sharma This paper is included in the Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’17). March 27–29, 2017 • Boston, MA, USA ISBN 978-1-931971-37-9 Open access to the Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation is sponsored by USENIX. Evaluating the Power of Flexible Packet Processing for Network Resource Allocation Naveen Kr. Sharma∗ Antoine Kaufmann∗ Thomas Anderson∗ Changhoon Kim† Arvind Krishnamurthy∗ Jacob Nelson‡ Simon Peter§ Abstract of the packet header, perform simple computations on Recent hardware switch architectures make it feasible values in packet headers, and maintain mutable state that to perform flexible packet processing inside the net- preserves the results of computations across packets. Im- work. This allows operators to configure switches to portantly, these advanced data-plane processing features parse and process custom packet headers using flexi- operate at line rate on every packet, addressing a ma- ble match+action tables in order to exercise control over jor limitation of earlier solutions such as OpenFlow [22] how packets are processed and routed. However, flexible which could only operate on a small fraction of packets, switches have limited state, support limited types of op- e.g., for flow setup. FlexSwitches thus hold the promise erations, and limit per-packet computation in order to be of ushering in the new paradigm of a software defined able to operate at line rate.
    [Show full text]
  • An Architecture for High-Speed Packet Switched Networks (Thesis)
    Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1989 An Architecture for High-Speed Packet Switched Networks (Thesis) Rajendra Shirvaram Yavatkar Report Number: 89-898 Yavatkar, Rajendra Shirvaram, "An Architecture for High-Speed Packet Switched Networks (Thesis)" (1989). Department of Computer Science Technical Reports. Paper 765. https://docs.lib.purdue.edu/cstech/765 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. AN ARCIITTECTURE FOR IDGH-SPEED PACKET SWITCHED NETWORKS Rajcndra Shivaram Yavalkar CSD-TR-898 AugusL 1989 AN ARCHITECTURE FOR HIGH-SPEED PACKET SWITCHED NETWORKS A Thesis Submitted to the Faculty of Purdue University by Rajendra Shivaram Yavatkar In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy August 1989 Il TABLE OF CONTENTS Page LIST OF FIGURES Vl ABSTRACT ................................... Vlll 1. INTRODUCTION 1 1.1 BackgroWld... 2 1.1.1 Network Architecture 2 1.1.2 Network-Level Services. 7 1.1.3 Circuit Switching. 7 1.1.4 Packet Switching . 8 1.1.5 Summary.... 11 1.2 The Proposed Solution. 12 1.3 Plan of Thesis. ..... 14 2. DEFINITIONS AND TERMINOLOGY 15 2.1 Components of Packet Switched Networks 15 2.2 Concept Of Internetworking .. 16 2.3 Communication Services .... 17 2.4 Flow And Congestion Control. 18 3. NETWORK ARCHITECTURE 19 3.1 Basic Model . ... 20 3.2 Services Provided. 22 3.3 Protocol Hierarchy 24 3.4 Addressing . 26 3.5 Routing .. 29 3.6 Rate-based Congestion Avoidance 31 3.7 Responsibilities of a Router 32 3.8 Autoconfiguration ..
    [Show full text]
  • ICMP for Ipv6
    ICMP for IPv6 ICMP in IPv6 functions the same as ICMP in IPv4. ICMP for IPv6 generates error messages, such as ICMP destination unreachable messages, and informational messages, such as ICMP echo request and reply messages. • Information About ICMP for IPv6, on page 1 • Additional References for IPv6 Neighbor Discovery Multicast Suppress, on page 3 Information About ICMP for IPv6 ICMP for IPv6 Internet Control Message Protocol (ICMP) in IPv6 functions the same as ICMP in IPv4. ICMP generates error messages, such as ICMP destination unreachable messages, and informational messages, such as ICMP echo request and reply messages. Additionally, ICMP packets in IPv6 are used in the IPv6 neighbor discovery process, path MTU discovery, and the Multicast Listener Discovery (MLD) protocol for IPv6. MLD is used by IPv6 devices to discover multicast listeners (nodes that want to receive multicast packets destined for specific multicast addresses) on directly attached links. MLD is based on version 2 of the Internet Group Management Protocol (IGMP) for IPv4. A value of 58 in the Next Header field of the basic IPv6 packet header identifies an IPv6 ICMP packet. ICMP packets in IPv6 are like a transport-layer packet in the sense that the ICMP packet follows all the extension headers and is the last piece of information in the IPv6 packet. Within IPv6 ICMP packets, the ICMPv6 Type and ICMPv6 Code fields identify IPv6 ICMP packet specifics, such as the ICMP message type. The value in the Checksum field is derived (computed by the sender and checked by the receiver) from the fields in the IPv6 ICMP packet and the IPv6 pseudoheader.
    [Show full text]
  • Packet Processing with a Noc-Enhanced FPGA
    Bringing Programmability to the Data Plane: Packet Processing with a NoC-Enhanced FPGA Andrew Bitar, Mohamed S. Abdelfattah, Vaughn Betz Department of Electrical and Computer Engineering, University of Toronto, Toronto, ON, Canada fbitar, mohamed, [email protected] 4000 Abstract—Modern computer networks need components that can evolve to support both the latest bandwidth demands and 3500 new protocols and features. To address this need, we propose a new programmable packet processor architecture built from 3000 an FPGA containing an embedded Network-on-Chip (NoC). The 2500 architecture is highly flexible, providing more programmability than is possible in an ASIC-based design, while supporting 2000 throughputs of 400 and 800 Gb/s. Additionally, we show that our 1500 design is 1.7× and 3.2× more area efficient, and achieves 1.5× and 3.7× lower latency than the best previously proposed FPGA- 1000 based packet processor on complex and simple applications, (Gb/s) BW Tranceiver Total respectively. Lastly, we explore various ways a designer can take 500 advantage of the flexibility available in this architecture. 0 I. INTRODUCTION Stratix I Stratix II Stratix IV Stratix V Stratix X Computer networks have seen rapid evolution over the past Fig. 1: Transceiver bandwidth available on Altera Stratix devices has rapidly grown with every new generation. The three data points decade. “Cloud computing” and the “Internet of Things” are for each generation correspond to the device models with the three becoming household terms, as we move to an era where highest transceiver BW. computational power is offloaded from the PC and onto data centers located miles away.
    [Show full text]
  • Pathminer Powered Predictable Packet Processing
    PathMiner Powered Predictable Packet Processing John Sonchack and Jonathan M. Smith University of Pennsylvania f jsonch, jms [email protected] Abstract—Performance advances have made software packet Symbolic Execution Genetic Algorithms processing a compelling alternative to hardware. However, soft- Execution Tree Path Guided Supervised ware still lacks the delay predictability of hardware, an important Exploration Packet Evolution Learning property for security and quality of service. As a solution, we Path Constraints introduce PathMiner, an analysis tool that automatically builds ? Example Packets performance models for software packet processors at the fine ? granularity of per-packet execution times. PathMiner combines symbolic execution and genetic algorithms in an iterative feed- back loop to rapidly mine a packet processor binary for diverse packets that invoke complex execution paths. With these packets, PathMiner trains machine learning models that predict packet PathMiner execution times and paths based on raw packet header bytes. We Packet Processor Performance implement a prototype of PathMiner and test it by profiling Binary Models a software IP router. The evaluation shows that PathMiner’s models predict delay with low error – for over 40% of packets Fig. 1. PathMiner mines packet processors for execution paths and sample they predicted the router’s execution time to within 10 cycles. packets to train models. Closer examination shows that PathMiner’s effectiveness is due to higher execution path coverage than symbolic execution and the capability to generate diverse training samples efficiently. timing deadlines, e.g., processing one packet per cycle [29], PathMiner takes an important step towards making it practical [2], [15] to guarantee line rate.
    [Show full text]
  • Impressive Packet Processing Performance Enables Greater Workload Consolidation Single Intel® Xeon® Processor Platform Achieves Over 80 Mpps Throughput1
    Solution Brief Packet Processing on Intel® Architecture Impressive Packet Processing Performance Enables Greater Workload Consolidation Single Intel® Xeon® processor platform achieves Over 80 Mpps throughput1 With Intel® processors, it’s possible support teams, and faster time-to- to transition from using discrete market with a solution benefiting architectures per major workload from the economies of scale of the (application, control plane, packet server industry. Such a notable level and signal processing) to a single of consolidation is achievable through architecture that consolidates the industry-leading performance, I/O workloads into a more scalable and throughput and performance per watt simplified solution. This software- density – all on a standards-based based approach, depicted in Figure 1, platform. Solution providers listed in yields further benefits with Intel’s 4:1 this paper are ready to help equipment workload consolidation strategy. The architects jumpstart their next designs. hardware platform – based on general- purpose server technology – has been optimized using the best practices of 2011 2012 2013 the communications industry to ensure system robustness with core, memory Application and I/O scalability and performance Processing Intel® Xeon® Intel® Xeon® Next improvements, to meet network Processor Processor Generation operator’s low to high-end system C3500/C5500 E5-2600 series requirements. Control Processing Intel® QuickAssist This framework is made possible by Technology the high performance level of Intel Software Library processors plus the Intel® Data Plane Packet Development Kit (Intel® DPDK), which NPU/ASIC Processing greatly boosts packet processing Intel® Data Plane Development Kit performance and throughput, allowing more time for data plane applications. Signal As a result, telecom and network DSP DSP Processing Intel® Signal Processing equipment manufacturers (TEMs/ Development Kit NEMs) can take advantage of lower development costs, fewer tools and Figure 1.
    [Show full text]
  • High Level Synthesis Tool for High Speed Packet Processing
    Y.Wang & V.S.Pakki Y.Wang High Level Synthesis for Tool Master’s Thesis High Level Synthesis Tool for High Speed Packet Processing High Speed Packet Processing SpeedHigh Packet Yian Wang Venkata Soumya Pakki Series of Master’s theses Department of Electrical and Information Technology LU/LTH-EIT 2014-417 Department of Electrical and Information Technology, http://www.eit.lth.se Faculty of Engineering, LTH, Lund University, December 2013. High Level Synthesis Tool for High Speed Packet Processing by Yian Wang and Venkata Soumya Pakki Master’s of Science in System on Chip Department of Electrical and Information Technology Lund University Dec 2013 Abstract The main objective of this Master Thesis is to design and implement a high level synthesis tool for high speed packet processing. For a given network packet, determining the destination and performing the required alterations to the packet are the key parts of Packet Processing. The idea is to provide customers a customized Ethernet switch which is reliable and flexible. As a requirement for this, a high level packet processing language (PPL) is designed instead of any hardware descriptive language because of the regularity of packet processing. The packet processing is described in a powerful way based on the PPL. In this thesis, a design of Ethernet switch based on the PPL is proposed. Hardware implementation is done for the design and MyHDL is used as the hardware description language. Using Python, the compiled PPL program is translated into an hardware model. A tool has been developed which consists of a hardware generator and certain hardware infrastructures.
    [Show full text]
  • High Performance Packet Processing with Flexnic
    High Performance Packet Processing with FlexNIC Antoine Kaufmann1 Simon Peter2 Naveen Kr. Sharma1 Thomas Anderson1 Arvind Krishnamurthy1 1University of Washington 2The University of Texas at Austin fantoinek,naveenks,tom,[email protected] [email protected] Abstract newer processors. A 40 Gbps interface can receive a cache- The recent surge of network I/O performance has put enor- line sized (64B) packet close to every 12 ns. At that speed, mous pressure on memory and software I/O processing sub- OS kernel bypass [5; 39] is a necessity but not enough by it- systems. We argue that the primary reason for high mem- self. Even a single last-level cache access in the packet data ory and processing overheads is the inefficient use of these handling path can prevent software from keeping up with ar- resources by current commodity network interface cards riving network traffic. (NICs). We claim that the primary reason for high memory and We propose FlexNIC, a flexible network DMA interface processing overheads is the inefficient use of these resources that can be used by operating systems and applications alike by current commodity network interface cards (NICs). NICs to reduce packet processing overheads. FlexNIC allows ser- communicate with software by accessing data in server vices to install packet processing rules into the NIC, which memory, either in DRAM or via a designated last-level cache then executes simple operations on packets while exchang- (e.g., via DDIO [21], DCA [20], or TPH [38]). Packet de- ing them with host memory. Thus, our proposal moves some scriptor queues instruct the NIC as to where in server mem- of the packet processing traditionally done in software to the ory it should place the next packet and from where to read NIC, where it can be done flexibly and at high speed.
    [Show full text]
  • IMPLEMENTING VOICE OVER IP Copyright 6 2003 by John Wiley & Sons, Inc
    IMPLEMENTING VOICE OVER IP Copyright 6 2003 by John Wiley & Sons, Inc. All rights reserved. Published by John Wiley & Sons, Inc., Hoboken, New Jersey. Published simultaneously in Canada. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400, fax 978-750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, e-mail: [email protected]. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best e¤orts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
    [Show full text]