This document proposes a functional programming approach called PFQ/lang for packet processing on Linux middleboxes. PFQ/lang defines packet processing as compositions of monadic functions. It aims to improve programmability, interoperability, and multi-core support. The runtime executes PFQ/lang programs on the PFQ framework for accelerated packet I/O. Early results show PFQ/lang can express common use cases and achieves line-rate performance on real hardware.

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.

15. 15
PFQ/lang example
Haskell:
comp
=
ip
>-­‐>
forward
"eth1"
>-­‐>
log_msg
"IP
packet"
>-­‐>
addr
"192.168.0.0"
16
>-­‐>
(when’
is_icmp
log_packet)
>-­‐>
kernel
C++11:
auto
comp
=
ip
>>
forward
("eth1")
>>
log_msg
("IP
packet")
>>
addr
("192.168.0.0",16)
>>
when(is_icmp,
log_packet)
>>
kernel;

16. 16
PFQ/lang use cases
Port mirroring
forward
"eth1"
>-­‐>
kernel
Smart Bridging
(when
is_udp
(forward
"eth1"))
>-­‐>
kernel
tap
"eth2"
is_rtp
>-­‐>
kernel
Load Balancer
steer_flow
ip
>-­‐>
steer_link

17. 17
PFQ/lang use cases
Stateless Firewall
(when
has_port
22
&&
!address("131.114.0.0",
16)
drop)
>-­‐>
kernel
when
(bloom
16
["192.168.0.1",
"192.168.0.2"
...])
kernel
Monitoring (early stage application)
conditional
is_rtp
(class
0
>-­‐>
steer_flow)
class
1

18. 18
Performance
Speed test: 10Gb link, 64B packets, Xeon 6 cores x5650 (Nehalem) @2.67Ghz, 16G Ram + Intel
82599 10G (Debian Wheezy)

19. 19
Performance
Conditional: (when is_tcp steer_flow) bridge: tap is_udp “eth2”

20. 20
Performance
speed test: comparisons of different computations

21. 21
PFQ wiki and download
http://www.pfq.io
https://github.com/pfq/PFQ/wiki