Customizing OVS using P 4 Muhammad Shahbaz with

Customizing OVS using P 4 Muhammad Shahbaz with Sean Choi, Ben Pfaff, Chaitanya Kodeboyina, Changhoon Kim, Nick Mc. Keown, Nick Feamster, and Jen Rexford

Customizing OVS is Hard! Protocols Changes Features - Adding protocols and features requires - manual changes throughout the source tree - maintaining changes across newer versions - e. g. , adding a new field required touching 12 files adding a new action required touching 10 files

Customizing OVS is Hard! Changes applied manually Protocols Features - Manual changes are time-consuming and error prone

Customizing OVS is Hard! Protocols Changes specified as a program Features - What if we describe these changes as programs? - This has many benefits: a. Rapid addition of new protocols and features b. Automated testing and debugging c. Backward compatibility

Which language should we use for writing these programs

Should we use P 4 ? - It’s an open-source language - Describes different aspects of a packet processor a. Header and Fields b. Parser c. Actions d. Match-Action Tables e. Control-Flow

Compiling P 4 to ? - There are two main aspects: 1. Efficient mapping from P 4 to OVS? 2. Cost of programmability on performance?

A (Magnified) View of Slow-Path Runtime Configurations Flow Struct ingress Flow Extraction Architecture Miss Cache Fast-Path Lookup Hit Fast-Path Match-Action (MA) Slow-Path Pipeline Actions egress

Mapping P 4 to ? Runtime Configurations Flow Struct Match-Action Pipeline Header, Metadata, Valids, Stacks, Field Refs Parsed Representation Flow Extraction add/remove_header drop, no_op, add_to_field modify_field deparsing, Calculated Fields, generate_digest Actions Field Lists, Action Defs, Table Decls, Control-Flow

Mapping P 4 to ? Runtime Configurations Flow Struct Match-Action Pipeline Header, Metadata, Valids, Stacks, Field Refs Parsed Representation Flow Extraction add/remove_header Field Lists, Action Defs, Table Decls, Control-Flow drop, no_op, add_to_field modify_field deparsing, Calculated Fields, generate_digest Actions

Add/Remove Header and Deparsing - P 4 provides primitive actions for arbitrarily adding/removing headers to/from packets a. add_header b. remove_header - e. g. , for packet encapsulation and decapsulation - Deparser operation serializes the packet - Its algorithm is inferred from the parse graph

Add/Remove Header and Deparsing - In OVS, changes are applied directly on the packet using set_field() action in the Fast-Path (packet) Hit [set_field() …] Actions Fast-Path (packet) egress

Add/Remove Header and Deparsing - Whereas, in P 4, each header has a valid bit a. If it’s set, changes are written to the packet by the deparser b. Otherwise, packet is not modified - Thus, multiple set_field() operations can lead to no change, if header’s valid bit is not set at the time of deparsing

Add/Remove Header and Deparsing - This requires keeping a separate copy of each header (or flow) in the Fast-Path - Changes are applied directly to this header At deparsing stage, if the header is valid it’s written to the packet else it’s discarded (packet, flow) Hit [set_field(flow) …, deparse] Actions Fast-Path (packet) egress

Cost of Programmability on Performance? - There are three main factors that primarily affect the performance: 1. Packet Parsing 2. Packet Deparsing 3. Fast-Path Actions

Cost of Programmability on Performance? a. Layer 2 learning switch 10100 10000 9900 9800 9700 9600 9500 9400 9300 64 68 Vanilla P 4 Ov. S (-O 0) 72 128 536 1514 Packet Size (Bytes) P 4 (-O 0) Throughput (Mbps) Vanilla Ov. S b. Layer 3 simple router P 4 OVS (-O 0): no csum 12000 10000 8000 6000 4000 2000 0 64 128 256 536 Packet Size (Bytes) 1514

Future Work - Implement optimizations to avoid extra copies of the header (or flow) in the fast-path - using dead-code elimination and liveness analysis etc. - Provide support for general fast-path actions like add_to_field etc.

Questions? Source Code https: //goo. gl/jl. RHih Muhammad Shahbaz mshahbaz@cs. princeton. edu