Talks

Linux network stack has provided the most innovative TCP implementation, adopting a large number of protocol extensions and optimizations. However, we’ve known for a while that it does not perform well for transaction workloads, which involve a lot of small packets and large number of concurrent TCP connections.

Software based switching consumes CPU resources that can instead be offloaded to modern network adapters.

In this talk we propose switch acceleration where functionality is done by software and when possible/sensible to offload to HW utilizing the switchdev framework when possible. Our approach can be implemented using existing functionality of most modern NICs that already support packet classification, multiple send and receive rings, traffic shapers and L2/L3/L4 overlay networks encapsulation / decapsulation.

The talk gives an overview on how NetDEF/OpenSourceRouting tests the Quagga projects and discusses some of the challenges. In the talk we’ll go into the details on how we (as OpenSourceRouting) tests Quagga and the challenges we have with a multiplatform tool, supporting many different OS variations, CPU architectures and a community of various volunteers and commercial users. The goal of the talk is to give some inspiration to other projects on how to approach this and start a discussion.

The Linux networking stack support High-Availability (HA) and Link Aggregation (LAG) through usage of bonding/teaming drivers, where both set a software netdevice on top of two or more netdevs.

Those HA devices are set as "upper" devices acting over "lower" devices. The core networking stack uses notifier mechanism to announce setup/tear-down of such relations.

We show how to take advantage of standard bonding/team and their associated notifiers to reflect HW/LAG into HW and achieve enhanced functionality.

This talk covers the design and implementation of the nftables switchdev support. The goal is to introduce the audience to the new in-kernel infrastructure to represent the rulesets through a generic abstract syntax tree that can be easily transformed from the drivers into the hardware specific representation.

In this talk/paper, we provide a technical deep-dive into the eBPF architecture, comparing it to the classic BPF framework and how tc's (traffic control) packet classification in the kernel is making use of it.

The talk will discuss recently upstreamed features to the kernel and iproute2 and walk through some examples on how classifier/actions can be programmed in restricted C and loaded into the kernel on ingress/egress side with the help of llvm and tc. It'll also cover the topic of sharing eBPF maps and working with eBPF tail calls.

SR-IOV devices present improved performance for network virtualization, but pose limitations today on the ability of the hypervisor to manage the network. For instance, UDP and IP tunnels that are commonly used on the cloud are not supported today with SR-IOV. Flow based approaches like Open vSwitch and TC are common in managing virtual machine traffic. Both technologies are not supported with today's SR-IOV Linux driver model, which only allows to program MAC or MAC+VLAN based forwarding for virtual function traffic.

Linux is a popular OS for network switches, routers, hypervisors and other devices in the data center today. These deployments are using an increasing number of network interfaces, both physical and logical, pushing scaling and performance boundaries with the implementation.

This paper examines problems with increasing the number of network interfaces on Linux. We will mostly look at deployment and configurations on network switches, though the content discussed applies to all Linux deployments.

We plan to cover:

Zebra 2.0 is new version of open source networking software which is implemented from scratch. Planning to support BGP/OSPF/LDP/RSVP-TE and co-working with Lagopus as fast packet forwarder with OpenFlow support.

Qdiscs such as fq_codel can be used to reduce latency in the Linux network queues. But a network device driver that has (perhaps good) reason to pull packets out of the Linux qdisc before it is actually time to transmit them can reintroduce queuing latency (in some cases much more than we would like) and result in head-of-line blocking for traffic for which the qdisc configuration is supposed to provide prioritized low-latency service.