High-performance SDN with Programmable Hardware

Transcription

1 High-performance SDN with Programmable Hardware Dr Gordon Brebner Distinguished Engineer CTO Office Xilinx, Inc Santa Clara, CA USA December

2 Hardware and Software Traditionally, hardware is about: Architectures, circuits, data flow, fixed, scary And software is about: Algorithms, programs, control flow, flexible, friendly But now have soft hardware and hard software : Algorithm/architecture co-design possible Control flow/data flow co-design possible So don t assume just dumb hardware, smart software Indeed, the words hardware and software considered harmful 18

3 Current OpenFlow: The dumb hardware exponent Simple switches and standard processors with ISA for the processors to program the switches Match-action execution model 17

4 OpenFlow flow table incremental evolution OF 10 (Dec 2009): 12 fields (Ethernet, TCP/IPv4) OF 11 (Feb 2011): 15 fields (+ MPLS, inter-table metadata) OF 12 (Dec 2011): 36 fields (+ ARP, ICMP, IPv6, misc tweaks) OF 13 (Jun 2012): 40 fields (+ misc tweaks) OF 15 (dec 2014): 43 fields (+ misc tweaks) Observation: Fields are intimately associated with ossified protocols So the crude ISA isn t as flexible or simple as it may seem 16

5 What s programmable in a network switch? Control processors Network processors Queuing Lookup Special-function blocks Crypto Hashing Programmable logic (FPGA) 15

6 Programmable logic, 1990 Cell: 2-input logic gate 1000 cells Local wiring between cells Both programmable by writing to memory Circuit design tools used Can only implement simple functions 14 Research perspective: Gates and wiring to be programmed Scarce resource to be managed Limited to niche applications

7 Programmable logic, 2015 Cell: 6-input logic gate and 2 flip-flops Embedded function blocks and memories 4m cells Local and longer wiring between components All programmable by writing to memory Hardware design tools used Can implement complex systems 13 Research perspective: Software-style engineering Adaptable processing architectures Lower-power peer of CPU, GPU, NPU

8 Programming programmable logic Chip design experience Hardware Description Language (HDL) Cryptic results sometimes Behavior and performance Place & route (slow) Enhancements (for hardware guys ): Libraries of blocks Allow re-use and sharing In HDL, or pre-synthesized High-level synthesis Usually superset of subset of C Translated into HDL Abstraction needed for software guys 12

9 Xilinx SDNet Programmable Packet Processor Overall feature set, facilitated by programmable logic: 100G+ packet rate performance Domain-specific programming abstraction Perfect-fit hardware for reduced cost and power Micro-coded for run time programmability 11

10 PPP design flow and use model Packet processing specification Domain-specific programming language describing functions in packet-oriented terms Throughput, latency, resource, programmability requirements Compiler Firmware HDL description Customized PPP architecture Update firmware when required Xilinx tools FPGA bitstream Configure FPGA FPGA running Tailored packet processor 10

11 Throughput can be traded off with FPGA utilization Different raw throughputs obtained by varying data path width Raw throughput (Gb/s) ArpIcmp JustEth RtpIp4andIp6 TcpIp4andIp6 VlanAndMpls Device Utilisation (%)

12 Latency can be traded off with FPGA utilization Different latencies obtained by varying pipeline length Ellipses denote solutions with same throughput 8 Example of trade-offs for IPv4 packet forwarding path design 9

13 Latency can be traded off with programmability 7 High-level description specifies the packet processing functions Compiler optimizes implementation characteristics by providing just the required run-time programmability Latency (ns) vs Programmability Major changes to classification algorithm possible at run time No run-time programmability Protocols can be added or removed at run time Example of trade-offs for 30-protocol packet classification design

14 P4 New P4 Language Consortium at P4org First P4 Workshop at Stanford in June 2015 Appeared first in paper published in July 2014 P4: Programming Protocol-Independent Packet Processors P Bosshart, D Daly, G Gibb, M Izzard, N McKeown, J Rexford, C Schlesinger, D Talayco, A Vahdat, G Varghese, D Walker 6 P4 is a high-level language for programming protocol-independent packet processors P4 works in conjunction with SDN control protocols like OpenFlow In its current form, OpenFlow explicitly specifies protocol headers on which it operates This set has grown from 12 to 41 fields in a few years, increasing the complexity of the specification while still not providing the flexibility to add new headers In this paper we propose P4 as a strawman proposal for how OpenFlow should evolve in the future We have three goals: (1) Reconfigurability in the field: Programmers should be able to change the way switches process packets once they are deployed (2) Protocol independence: Switches should not be tied to any specific network protocols (3) Target independence: Programmers should be able to describe packet processing functionality independently of the specifics of the underlying hardware As an example, we describe how to use P4 to configure a switch to add a new hierarchical label

15 Xilinx Labs prototype demonstrated at P4 Workshop, June 2015 Front end: githubcom/p4lang/p4-hlir Mapper: new code written in Python SDNet: next product release version Xilinx VCU109 development board: Carries Virtex Ultrascale XCVU095 FPGA 5

16 Protocol Independent Forwarding How to tell your plumbing what to do Nick McKeown, ONF member workday keynote, September 2014 Nick s observation: Some switches are more programmable than fixed-function ASICs Proposed PIF approach: Phase 0 Initially, the switch does not know what a protocol is, or how to process packets (Protocol Independence) Phase 1 We tell the switch how we want it to process packets (Configuration) Phase 2 The switch runs (Run-time) 4

17 Expressing and mapping programmability 3 4

18 PIF Open Source Software project Incubated within ONF Focus areas of PIF project: Experimenting with IR elements Use cases Runtime APIs Feeds into ONF OpenFlow Next Gen specification activity 2 3

19 Conclusion SDN aspirations are good: flexibility, openness, innovation But SDN as broadly perceived is beholden to the processor An ossified technology dating back over 75 years Maybe because of convenience and/or because of popularity Innovation in platforms matters too Pursue integration of heterogeneous programmable technologies with high-level programming abstractions Looking to devise scalable solutions: from 1 Mb/sec to 1 Tb/sec Then open up the network programmability to applications Configure the platform, and then operate the data plane 1

20 0