P4 introduction - USI Informatics · P4 introduction . The P4 Language Consortium ... 24; /* gnve/vxlan vnid/gre key / tun_type : 8; / vxlan; gre; nvgre; gnve/ tun_idx : 8; /

1 2015 SIGCOMM P4 tutorial

P4 introduction

The P4 Language Consortium

•  Consortium of academic and industry members •  Open source, evolving, domain-specific language •  Permissive Apache licence, code on GitHub today •  Membership is free : contributions are welcome

http://www.p4.org

Problem statement http://www.p4.org

•  Fragmented space of data plane languages

•  Virtually all are closed/proprietary

•  Very low level (think assembly language)

•  Tightly coupled to (a series of) devices

•  No re-use, no incremental development

•  Little or no collaboration on foundational behaviors

•  Little or no code commonality –> wheel reinvention

•  (problems… oh yes: there are more…)

Proposed solutions (P4) http://www.p4.org

•  high-level & domain-specific

•  open source, open specifications

•  modular compiler architecture

•  protocol independent

•  device (“target”) independent


P4 Modular Compilation

Control Flow & Parse Graphs

PD-Lib and P4-pgm

Simulation Library

p4c-validate & p4c-graph

Target Drivers Stack

P4 Compiler (p4c-fe)

Outputs

Backend Targets

Frontend

p4c-behavioral

HLIR

P4 program

Intermediate Representation

Target X

Target Y


Modular Compiler Overview

•  P4 translated to Python high level intermediate representation (HLIR) o  Full access to HLIR makes it easy to add functionality like

customized code generation • Multiple backend targets

o  software switches o  network interface cards o  packet processors / NPUs o  FPGAs, GPUs, ASICs o Validation and graph generators o Automatic generation of run time APIs


Programmable Switch Approach

Fixed Meta-Data

Traffic Manage

r

Fixed Parser

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixed Packe

t Mods

Fixed Function ASIC

Programmable Meta-Data

Traffic Manager

Flex

ible

P

arse

r Flex

ible

Lo

okup

s

Shared Memories

Cus

tom

A

ctio

ns

Flex

ible

Lo

okup

s

Shared Memories

Cus

tom

A

ctio

ns

Flex

ible

Lo

okup

s

Shared Memories

Cus

tom

A

ctio

ns

Flex

ible

Lo

okup

s

Shared Memories

Cus

tom

A

ctio

ns

DeP

arse

r

Programmable target

dc.p4

(P4 code) Protocol Authoring

1

Compile 2

Configure 3

Auto Generated Run-‐?me API


Result: Customer Defined Switch

Switch OS

Driver

Fixed Meta-Data

Traffic Manage

r

Fixed Parser

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixe

d Lo

okup

s

Fixed Memories

Fixe

d Lo

okup

s

Fixed Packe

t Mods

Fixed Function ASIC

User Defined Meta-Data

Traffic Manager

Use

r Def

ined

P

arse

r Use

r D

efin

ed

Look

ups

User Defined Tables

Use

r D

efin

ed

Act

ions

Use

r D

efin

ed

Look

ups

User Defined Tables

Use

r D

efin

ed

Act

ions

Use

r D

efin

ed

Look

ups

User Defined Tables

Use

r D

efin

ed

Act

ions

Use

r D

efin

ed

Look

ups

User Defined Tables

Use

r D

efin

ed

Act

ions

Use

r Def

ined

D

ePar

ser

Programmable ASIC : User Defined Forwarding Plane

Run! 4

Add/delete table rules

Auto Generated Run-‐?me API


High Level P4/PISA Abstraction

I N P U T

O U T P U T

P A R S E R

Match Ac?on

Queues and/or Buffers

Switch Configura?on

Match+Ac?on Table Config

Parse Graph

Run Time Forwarding rules

Match Ac?on

Control Program

Ingress Match+Ac/on Egress Match+Ac/on Packet Modifica;ons +

Egress Selec/on Packet Modifica;ons


Components of a P4 Program

• Sections o Headers and Fields o The Parser o Match+Action Table Specification o Actions o Control Flow o Counters, Meters and Stateful Memories


Headers and Fields

header_type ethernet_t { fields { dstAddr : 48; srcAddr : 48; etherType : 16; }}

/* Instance of eth header */header ethernet_t inner_ethernet;

header_type egress_metadata_t { fields { nhop_type : 8; /* 0: L2, 1: L3, 2: tunnel */ encap_type : 8; /* L2 Untagged; L2ST; L2DT */ vnid : 24; /* gnve/vxlan vnid/gre key */ tun_type : 8; /* vxlan; gre; nvgre; gnve*/ tun_idx : 8; /* tunnel index */ }}

metadata egress_metadata_t egress_metadata;

Metadata is a header instance

•  Fields have a width and other attributes •  Headers are collections of fields •  These are types which are used to declare instances


Programmable Parser •  Programmable parser •  Produces a parsed representation of the packet •  All match/action fields are generic •  No specific protocols are embedded in the program

Parser

TCP New

IPv4 IPv6

VLAN Eth

Parser Ingress Match+Ac?on Egress Match+Ac?on Queues

TCP New

IPv4 IPv6

VLAN Eth


The Parser

parser parse_ethernet { extract(ethernet); return select(latest.etherType) { ETHERTYPE_CPU : parse_cpu_header; ETHERTYPE_VLAN : parse_vlan; ETHERTYPE_MPLS : parse_mpls; ETHERTYPE_IPV4 : parse_ipv4; ETHERTYPE_IPV6 : parse_ipv6; ETHERTYPE_ARP : parse_arp_rarp; ETHERTYPE_RARP : parse_arp_rarp; ETHERTYPE_NSH : parse_nsh; }}

•  Imperative functions for “states” •  Extract header instances •  Select a next “state” by returning a parser function

•  Produces a Parsed Representation of the packet


Parser code (with header defs in blue) #define ETHERTYPE_IPV4 0x0800

header ethernet_t ethernet;

parser parse_ethernet { extract(ethernet); return select(latest.etherType) { ETHERTYPE_IPV4 : parse_ipv4; default: ingress; }}

header ipv4_t ipv4;

field_list ipv4_checksum_list { ipv4.version; ipv4.ihl; ipv4.diffserv; ipv4.totalLen; ipv4.identification; ipv4.flags; ipv4.fragOffset; ipv4.ttl; ipv4.protocol; ipv4.srcAddr; ipv4.dstAddr;}

field_list_calculation ipv4_checksum { input { ipv4_checksum_list; } algorithm : csum16; output_width : 16;}

calculated_field ipv4.hdrChecksum { verify ipv4_checksum; update ipv4_checksum;}

parser parse_ipv4 { extract(ipv4); return ingress;}

header_type ethernet_t { fields { dstAddr : 48; srcAddr : 48; etherType : 16; }}

header_type ipv4_t { fields { version : 4; ihl : 4; diffserv : 8; totalLen : 16; ident : 16; flags : 3; fragOffset : 13; ttl : 8; protocol : 8; hdrChecksum : 16; srcAddr : 32; dstAddr: 32;


The Parsed Representation

•  The parser produces a “Parsed Representation” (PR) of the packet

• Match+action tables operate on the PR •  Any value used by the program must be in the PR •  (or metadata from the target)


Review of Processing

•  The parser extracts headers into the PR •  The PR is processed by match+action tables

o  fields and metadata can be rewritten o  compiler determines ordering domains

•  The PR is re-serialized for egress


Control Flow •  Specified imperatively •  Compiler manages table ordering and dependencies •  Actions are “called” by tables: not called explicitly (*)

* You can call an action without a match by using an “empty” table

control ingress {if (valid(vlan_tag[0])) { apply_table(choose_input_intf); } apply_table(bridge_domain); if (valid(mpls_bos)) { apply_table(mpls_label); }

. . . .}


Match+Action Tables

•  Specification of: o  What to examine from each packet o  What are the permitted actions that can be applied o  What resources to allocate to the table

•  Let’s look at a table that maps an incoming packet to a logical incoming interface

•  Common early processing step for forwarding planes o  We attach input features like VPN, ACLs, bridge

domains, etc to these input interfaces


Match+Action Tables


table choose_input_intf { reads { standard_metadata.ingress_port : exact;

vlan_tag : valid; vlan_tag.vid : exact; } actions { drop;

ingress_intf_extract; } size 16384;}


Match+Action Tables

•  Specification of: o  What to examine from each packet o  What are the permitted actions? o  What resources to allocate to the table





Match+Action Tables






Match+Action Tables




ingress port

tag valid?

VLAN id

Action Parameters

eth0 0 X drop counter

eth0 1 101 extract intf=A, brdomain=B, VRF=C

eth0 1 102 extract intf=L, brdomain=M, VRF=N

eth1 1 101 extract intf=W, brdomain=X, VRF=Y

logical table view (physical view shortly!)


Action Functions

•  Specified imperatively from primitives o  modify field (packet header or metadata) o  add/remove header o  counter/meter/stateful memory operations

/* Ingress logical interface setup */action set_ingress_intf(i_lif, bd, vrf, v4term) { modify_field(route_md.i_lif, i_lif); modify_field(route_md.bd, bd); modify_field(route_md.vrf, vrf); modify_field(route_md.ipv4_term, v4term, 0x1); . . .}


Tables and Actions in the switch

action ing_lif_extract(i_lif, bd, vrf) { . . . .}

i_lif Ing Port VLAN id bd vrf 01001010110011

Match key Action Parameters Action Instruction

P4 + Compiler: Gives format of match and action entries; determines action instructions Run time population: Determines the values used for match and action data

table choose_input_intf { reads { standard_metadata.ingress_port : exact; vlan_tag[OUTER_VLAN_IDX].vid : exact; } actions { drop; ing_lif_extract; } . . . .} Table

Entry


Special tables / primitives

•  Counters o may be indirect, direct, or static

•  indirect : counter and a reference •  direct: bound 1:1 with table entries •  static: bound statically to a single table

• Meters o  similar to a counter, but returns a status o  generally green, yellow, red, etc.

•  Registers o  tables that are read/write by actions o  allows state to be stored between subsequent packets


Example Generated API

entry_handle_t host_route_table_add_with_route( uint16_t routing_metadata_vrf, uint32_t ipv4_dstAddr, uint32_t action_ecmp_count, uint32_t action_ecmp_base);

action route(ecmp_count, ecmp_base) { modify_field( routing_metadata.ecmp_count, ecmp_count); modify_field( routing_metadata.ecmp_base, ecmp_base); add_to_field(ipv4.ttl, -1);}

table host_route { reads { routing_metadata.vrf : exact; ipv4.dstAddr : exact; } actions { host_route_miss; /* default */ route; }}

Table ref

Ac?on select






Match parameters






Ac?on parameters


Thank you

Documents

P4 introduction - USI Informatics · P4 introduction . The P4 Language Consortium ... 24; /* gnve/vxlan vnid/gre key */ tun_type : 8; /* vxlan; gre; nvgre; gnve*/ tun_idx : 8; /*

P4 introduction - USI Informatics · P4 introduction . The P4 Language Consortium ... 24; /* gnve/vxlan vnid/gre key / tun_type : 8; / vxlan; gre; nvgre; gnve/ tun_idx : 8; /