A purely functional approach to packet processing with PFQ/lang
1. A purely functional approach to
packet processing
Nicola Bonelli
Nicola Bonelli, Stefano Giordano, Gregorio Procissi
University of Pisa
Luca Abeni
University of Trento
2. 2
Facts on Linux
● Linux is a general purpose operating system often used
to create middleboxes
o large amount of open source software
o a feature-rich subsystem of networking
● The kernel provides
o network stack supports a large amount of protocols
o traffic control (tc), firewall (netfilter)
o routing (iproute2), bridging
o monitoring facilities (AF_PACKET and BPF filters)
● Open-source kernel modules
o PF_RING-DNA / Netmap (accelerated drivers)
o PFQ framework for multi-core architectures
3. 3
Motivation
● What’s wrong with Linux as a middlebox?
o Components are designed to be configurable
! programmability is not fully addressed
● only low level libraries enable tools to communicate to the kernel
o Interoperability among heterogeneous components?
! components are statically linked to each other
! what about bridging packets that satisfy a given BPF ?
o With no virtual machines, the configuration is system-wide
! Multiple applications can concurrently manage the networking for different
purposes?
4. 4
Objective
● Design a new language for programmable middleboxes
that:
o at high level enables reusability and interoperability among kernel components
! interfaces, kernel and sockets are end-points
o is multi-thread oriented by design
! allows concurrent execution of networking applications
o as much close as possible to NICs
● But where to implement it?
o Use PFQ as underlying architecture
5. 5
Why PFQ?
● Multi-language framework
o C, C++11-14, Haskell
o compliant with a plethora of device drivers
o line-speed with Intel vanilla drivers (14.8Mpps)
● Flexible parallelism
o decouple software from hardware parallelism
● Address multi-core architectures
o scale almost linearly in any possible configuration
● Best practices of concurrent programming
o no mutexes, no spinlocks in fast data-path
o amortized atomic operations
6. 6
PFQ/lang overview
● PFQ/lang as a functional language
! DLS describing networking application as a sequence of elementary operations
(functions)
! simple firewall, bridge, load balancer, etc.
! early stage of monitoring applications (dispatcher)
● A PFQ/lang program consists of a functional composition
o takes a packet and return a packet enriched with a context
! information about the distribution (Fanout)
! state, annotation (State) etc.
! possible side effect (IO)
7. 7
PFQ/lang features
● strongly typed language
● high-order functions
o functions that take functions as argument (i.e. conditional expressions)
● currying
o Used to bind arguments in user-space
" string, vectors, trivially copyable objects in C++
" storable types, storable tuples, list in Haskell
● immutability of data
o COW (copy-on-write)
● deterministic garbage collector (GC)
o Value semantic with no impact on performance
8. 8
PFQ/lang principles
● PFQ/lang computations are defined in user-space
o C++11/Haskell eDSL
● AST is transferred to kernel module for a group of
endpoints
o runtime strict type-checking (to avoid kernel panic)
● Converted into an executable data structure by a
runtime linker
o structure with data and pointers to functions
● … and executed on top of network device drivers
9. 9
PFQ/lang current state
● In-kernel functions are implemented in C language
o reusability of Linux kernel functions
o about a hundred of functions ready to use
o functional library eases the implementation
● The runtime linker is extensible
o users can add custom functions and make them available
in the DLS
● What is missing...
o grammar parser for computations from text
o PFQ/lang native compiler
10. 10
PFQ/lang theory (in short)
● Fanout, State and IO can be seen as mathematical abstractions
called monads (category theory)
● Monads are data structures that represent computations
o extend pure functions with side effect
● PFQ/Lang elementary operations are monadic functions
o Action: fanout monad, IO monad and state monad.
● Functional composition of monadic functions with the Kleisli
operator
11. 11
Monads: fanout and state
● Fanout monad is designed to model packet dispatching
o fanout values can be: Drop,
Pass,
Broadcast,
Steer,
Deliver
and
Dispatch
Drop => drop the packet
Pass => pass this packet to the next function
Broadcast => broadcast this packet to all the endpoints of this group
Deliver => send the packet to the endpoints of the given class
Steer => send the packet to an endpoint by means of a hash (random)
Dispatch => combination of Deliver + Steer
● State monad is designed to model a mutable state
o the state is associated with the computation
simple state, used to mark packets
o persistent state assiciated with flows
12. 12
IO monad
● IO monad (+GC) is used to implement packet
forwarding
o lazy implementation
carried out after the computation is evaluated
● Lazy means faster!
o A shallow copy per packet forwarding
o The last forward can be done without the copy
o A posteriori with lazy forwarding we can save
the last skb_clone
13. 13
PFQ/lang simple functions
● Simple functions are divided into the following categories:
o predicates:
! is_ip,
is_udp,
is_tcp,
is_icmp,
is_ip6,
is_udp6,
is_tcp6,
is_flow,
is_frag,
is_first_frag,
is_more_frag,
has_port,
has_src_port,
has_dst_port,
has_vlan,
has_vid,
bloom
etc...
o combinators:
! ||,
&&,
^^
(binary),
not
(unary)
o properties:
! ip_tos,
ip_tot_len,
ip_id,
ip_frag,
ip_ttl,
tcp_src,
tcp_dst,
tcp_hdrlen,
udp_src,
udp_dst,
udp_len,
icmp_type,
icmp_code...
o comparators:
! >,
>=,
<,
<=,
==,
/=,
any_bit,
all_bit
14. 14
PFQ/lang monadic functions
● Monadic functions are divided into the following categories:
o filters:
! ip,
ip6,
udp,
tcp,
udp6,
tcp6,
icmp,
icmp6,
flow,
rtp,
no_frag,
no_more_frag,
vlan_filter,
bloom_filter,
etc.
o steering functions:
! steer_link,
steer_vlan,
steer_ip,
steer_ip6,
steer_flow,
steer_rtp,
steer_net,
steer_field
o conditionals:
! when,
unless,
conditional
o others:
! kernel,
forward,
bridge,
tee,
tap,
inv,
par,
log_msg,
log_packet,etc.