BEGIN:VCALENDAR VERSION:2.0 PRODID:-//CERN//INDICO//EN BEGIN:VEVENT SUMMARY:Closing Plenary (Floriana I/II/III) DTSTART;VALUE=DATE-TIME:20190911T174500Z DTEND;VALUE=DATE-TIME:20190911T183000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION: LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Last Bus service - 11PM DTSTART;VALUE=DATE-TIME:20190911T215500Z DTEND;VALUE=DATE-TIME:20190911T220000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION: LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Closing Party @ Centro Cultural de Belém (CCB) DTSTART;VALUE=DATE-TIME:20190911T190000Z DTEND;VALUE=DATE-TIME:20190911T215500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Closing Party will be held at the Centro Cultural de Belém (C CB). Accessible by bus starting from the entrance (upstairs) behind the LP C registration desk.\n\nLast return bus: 11PM\n\nhttps://linuxplumbersconf .org/event/4/contributions/568/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Bus service for Evening Party DTSTART;VALUE=DATE-TIME:20190911T183000Z DTEND;VALUE=DATE-TIME:20190911T190000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Buses will start circulating at 7:30PM. \n\nLast return bus is at 11PM\n\n LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Improving Route Scalability with Nexthop Objects DTSTART;VALUE=DATE-TIME:20190911T110000Z DTEND;VALUE=DATE-TIME:20190911T114500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: David Ahern ()\nRoute entries in a FIB tend to be ve ry redundant with respect to nexthop configuration with many routes using the same gateway\, device and potentially encapsulations such as MPLS. The legacy API for inserting routes into the kernel requires the nexthop data to be included with each route specification leading to duplicate process ing verifying the nexthop data\, an effect that is magnified as the number of paths in the route increases (e.g.\, ECMP).\n\nA new API was recently committed to the kernel for managing nexthops as separate objects from rou tes. The nexthop API allows nexthops to be created first and then routes c an be added referencing the nexthop object. This API allows routes to be m anaged with less overhead (e.g.\, dramatically reducing the time to insert routes) and enables new capabilities such as atomically updating a nextho p configuration without touching the route entries using it.\n\nThis talk will discuss the nexthop feature touching on the kernel side implementatio n\, reviewing the userspace API and what to expect for notifications\, per formance improvements and potential follow on features. While the nexthop API is motivated by Linux as a NOS\, it is useful for other networking dep loyments as well such as routing on the host and XDP.\n\nhttps://linuxplum LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Linux Kernel VxLan with Multicast Routing for flood handling DTSTART;VALUE=DATE-TIME:20190909T090000Z DTEND;VALUE=DATE-TIME:20190909T094500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Roopa Prabhu (Roopa)\nThe Linux kernel VxLan driver supports two ways of handling flooded traffic to multiple remote VxLan ter mination end points (VTEPS):\n(a) Head end replication: where the VxLan dr iver sends a copy of the packet to each participating remote VTEPs\n(b) Us e of multicast routing to forward to participating remote VTEPs\n\n(b) is generally preferred for both hardware and software VTEP deployments becaus e it scales better. The kernel VxLan driver supports (b) with static confi g today. One has to specify the multicast group with the outgoing uplink i nterface for VxLan multicast replication to work. This is mostly ok for de ployments where VTEPs are deployed on the host/hypervisor. When deploying Linux VTEPs on the Top-Of-the-Rack (TOR) switches in a data center CLOS ne twork\, it is impossible to configure the outgoing interface statically. T ypically a multicast routing protocol like PIM is used to dynamically calc ulate multicast trees and install forwarding paths for multicast traffic. \n\nIn this talk we will cover:\n- Vxlan Multicast deployment scenarios wi th Vxlan VTEPs at the TOR switches\n- Current challenges with integrating Vxlan Multicast replication in a dynamic multicast routing environment\n- Solutions to these challenges: (a) Patches to fix routing of locally gener ated multicast packets (need for ip_mr_output) (b) Patches to VxLan driver to allow multicast replication without a static outgoing interface\n- Sca le\n- Futures on VxLan deployments in multicast environment\n\nhttps://lin LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:XDP: the Distro View DTSTART;VALUE=DATE-TIME:20190910T090000Z DTEND;VALUE=DATE-TIME:20190910T100000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Jiri Benc (Red Hat)\, Toke Høiland-Jørgensen (RedH at)\, Jesper Dangaard Brouer (Red Hat)\nIt goes without saying that XDP is wanted more and more by everyone. Of course\, the Linux distributions wan t to bring to users what they want and need. Even better if it can be deli vered in a polished package with as few surprises as possible: receiving b ug reports stemming from users' misunderstanding and from their wrong expe ctations does not make good experience neither for the users nor for the d istro developers.\n\nXDP presents interesting challenges to distros: from the initial enablement (what config options to choose) and security consid erations\, through user supportability (packets "mysteriously" disappearin g\, tcpdump not seeing everything)\, through future extension (what happen s after XDP is embraced by different tools\, some of those being part of t he distro\, how that should interact with users' XDP programs?)\, to more high level questions\, such as user perception ("how comes my super-import ant use case cannot be implemented using XDP?").\n\nSome of those challeng es are long solved\, some are in progress or have good workarounds\, some of them are yet unsolved. Some of those are solely the distro's responsibi lity\, some of them need to be addressed upstream. The talk will present t he challenges of enabling XDP in a distro. While it will also mention the solved ones\, its main focus are the problems currently unsolved or in pro gress. We'll present some ideas and welcome discussion about possible solu tions using the current infrastructure and about future directions.\n\nhtt ps:// LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Multipath TCP Upstreaming DTSTART;VALUE=DATE-TIME:20190909T110000Z DTEND;VALUE=DATE-TIME:20190909T114500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Mat Martineau (Intel)\, Matthieu Baerts (Tessares)\n Multipath TCP (MPTCP) is an increasingly popular protocol that members of the kernel community are actively working to upstream. A Linux kernel fork implementing the protocol has been developed and maintained since March 2 009. While there are some large MPTCP deployments using this custom kernel \, an upstream implementation will make the protocol available on Linux de vices of all flavors.\n\nMPTCP is closely coupled with TCP\, but an implem entation does not need to interfere with operation of normal TCP connectio ns. Our roadmap for MPTCP in Linux begins with the server use case\, where connections and additional TCP subflows are generally initiated by peer d evices. This will start with RFC 6824 compliance\, but with a minimal feat ure set to limit the code footprint for initial review and testing.\n\nThe MPTCP upstreaming community has shared a RFC patch set on the netdev list that shows our progress and how we plan to build around the TCP stack. We 'll share our roadmap for how this patch set will evolve before final subm ission\, and discuss how this first step will differ from the forked imple mentation.\n\nOnce we have merged our baseline code\, we have plans to con tinue development of more advanced features for managing subflow creation (path management)\, scheduling outgoing packets across TCP subflows\, and other capabilities important for client devices that initiate connections. This includes making use of a userspace path manager\, which has an alpha release available already. In future kernel releases we will make use of additional TCP features and optimize MPTCP performance as we get more feed back from kernel users.\n\nBoth the communication and the code are public and open. You can find us at and stream\n\n LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:SwitchDev offload optimizations DTSTART;VALUE=DATE-TIME:20190909T164500Z DTEND;VALUE=DATE-TIME:20190909T173000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Allan Nielsen ()\nLinux has a nice SW bridge impleme ntation which provides most of the classic\nEthernet switching features. D SA and SwitchDev frameworks allow us to\nrepresent HW switch devices in Li nux and potentially offload the SW forwarding\nto HW.\n\nBut the offloadin g facilities are not perfect\, and there seem to be room for\nfurther impr ovements:\n\n- Limiting the flooding of L2-Multicast traffic. IGMP snoopin g can limit the\n flooding of L3 traffic\, but L2-Multicast traffic are a lways flooded.\n\n- Today all bridge slave interfaces are put into promisc uous mode to allow\n learning/flooding. But if the bridge is offloaded wi th HW capable of doing\n learning/learning\, then this should not be nece ssary.\n\n- When not put into promiscuous mode\, the `struct net_device` s tructure has a\n list of multicast addresses which should be received by the interface. But\n when VLAN sub-interfaces are created\, the VLAN info rmation is lost when\n addresses are installed in the `mc` list.\n\n- The assumption in the bridge code is that all multicast frames goes to the\n CPU. But what would it actually take only to request the needed multicast \n frames to the CPU?\n\n- Challenges in adding new redundancy and protec tion protocols to the kernel\,\n and how to offload such protocols to HW. \n\nThe intend with the talk is to present some of the issues we are facin g in\nadding DSA/SwitchDev drivers for existing and near-time future HW. I will have few solutions to present\, but will give our thoughts on how it may be solved. Hopefully with will result in good discussions and input f rom the audience.\n\nBackground information: I'm working on a SwitchDev dr iver for a yet to be\nreleased HW Ethernet switch. It will be a TSN switch targeting industrial\nnetworks\, with HW accelerators to implement redund ancy protocols. CPU power are very limited\, and latency are extremely imp ortant\, which is why it is important for us to improve the HW offload fac ilities.\n\n LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Life at a Networking Vendor -- Keeping up with the Joneses DTSTART;VALUE=DATE-TIME:20190910T110000Z DTEND;VALUE=DATE-TIME:20190910T114500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Andy Gospodarek (Broadcom)\nWorking for a networking hardware vendor can be an extremely rewarding experience for a kernel dev eloper. The rate at which new features are accepted in the kernel also pr ovides lots of motivation to develop new features that showcase hardware c apabilities. This could be done by adding new support for dataplane offlo ads via cls flower\, netfilter\, or switchdev (if we still think it exists !). In-driver support for pre-SKB packet processing via XDP and AF_XDP al so provide a chance for developers to search for new software optimization s in their driver receive and transmit path.\n\nIn addition to thinking ab out what is happening upstream\, developers at hardware vendors regularly find themselves managing internal and external expectations from those res ponsible for developing features that are not always exclusive to the Linu x kernel. This could range from frameworks like DPDK and VPP that run on Linux or completely different OSes/stacks to functionality that is availab le without software interaction.\n\nThere is no quicker way to develop new features and resolve issues than to have direct contact with hardware and firmware developers. The goal of this talk will be to share some experie nces balancing the expectations of customers and partners along with those of the community.\n\n 491/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Ethernet Cable Diagnostic using Netlink Ethtool API DTSTART;VALUE=DATE-TIME:20190910T164500Z DTEND;VALUE=DATE-TIME:20190910T173000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Andrew Lunn ()\nMany Ethernet PHYs contain hardware to perform diagnostics of the\nEthernet cable. Breaks in the cable and sho rts within a twisted pair\nor to other pairs can be detected\, and an esti mate to the length along\nthe cable to the fault can be made. The talk wil l explain\, at a high\nlevel\, how such diagnostics work\, sending pulses down the cables and\nlooking for reflections. There is no standardization on such\ndiagnostics\, and what information the PHY reports varies between \nvendors. The ongoing work to allow ethtool to make use of a netlink\nsoc ket makes the ethtool API much more flexiable. This flexibility has\nbeen used to provide a generic API to request a PHY performs\ndiagnostics tests and to report the results. Some aspects of this API\nwill be discussed\, using the Marvell PHYs as examples. The talk aims\nto spread knowledge on this work and encourage driver writers to\nimplement diagnostics for other PHYs.\n\n LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Scaling container policy management with kernel features DTSTART;VALUE=DATE-TIME:20190911T090000Z DTEND;VALUE=DATE-TIME:20190911T094500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Joe Stringer (\nCilium is an open source p roject which implements the Container Network\nInterface (CNI) to provide networking and security functions in modern\napplication environments. The primary focus of the Cilium community recently\nhas been on scaling these functions to support thousands of nodes and hundreds\nof thousands of con tainers. Such environments impose a high rate of churn as\ncontainers and nodes appear and leave the cluster. For each change\, the\nnetworking plug in needs to handle the incoming events and ensure that policy is\nin sync with network configuration state. This creates a strong incentive to\neffi ciently interpret and map down cluster events into the required Linux\nnet working configuration to minimize the window during which there are\ndiscr epancies between the desired and realized state in the cluster---something \nthat is made possible through eBPF and other kernel features.\n\nCilium realizes these policy and container events through the use of many\naspect s of the networking stack\, from rules to routes\, tc to socket hooks\,\ns kb->mark to the skb->cb. Modelling the changes to datapath state involves a\nnon-trivial amount of work in the userspace daemon to structure the des ired\nstate from external entities and allow incremental adjustments to be made\,\nkeeping the amount of work required to handle an event proportion al to its\nimpact on the kernel configuration. Some aspects of datapath co nfiguration such\nas the implementation of L7 policy have gone through mul tiple iterations\, which\nprovides a window for us to explore the past\, p resent and future of transparent\nproxies.\n\nThis talk will discuss the c ontainer policy model used by Cilium to apply\nwhitelist filtering of requ ests at layers 3\, 4 and 7\; memoization techniques\nused to cache interme diate policy computation artifacts\; and impacts on\ndataplane design and kernel features when considering large container based\ndeployments with h igh rates of change in cluster state.\n\n nt/4/contributions/464/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:An Evaluation of Host Bandwidth Manager DTSTART;VALUE=DATE-TIME:20190911T114500Z DTEND;VALUE=DATE-TIME:20190911T123000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Lawrence Brakmo (Facebook)\nHost Bandwidth Manager ( HBM) is a BPF based framework for managing per-cgroupv2 egress and ingress bandwidths in order to provide a better experience to workloads/services coexisting within a host. In particular\, HBM allows us to divide a host's egress and ingress bandwidth among workloads residing in different v2 cgr oups. Note that although sample BPF programs are included in the BPF patch es\, one can easily use different algorithms for managing bandwidth.\n\nTh is talk presents an evaluation of HBM and associated BPF programs. It expl ores the performance of various approaches to bandwidth management for TCP flows that use Cubic\, Cubic with ECN or DCTCP for their congestion contr ol. For evaluating performance\, we consider how well flows can utilize th e allocated bandwidth\, how many packets are dropped by HBM\, increases to RTTs due to queueing\, RPC size fairness\, as well as RPC latencies. This evaluation is done independently for egress and ingress. In addition\, we explore the use of HBM for protecting against incast congestion by also u sing HBM on the root v2 cgroup.\n\nOur testing shows that HBM\, with the a ppropriate BPF program\, is very effective at managing egress bandwidths r egardless of which TCP congestion control algorithm is used\, preventing f lows from exceeding the allocated bandwidth while allowing them to use mos t of their allocation. Not surprisingly\, effectively managing ingress ban dwidth requires ECN\, and preferably DCTCP. Finally\, we show that using H BM is very effective at preventing packet losses due to incast congestion\ , as long as we are willing to sacrifice some ingress bandwidth.\n\nhttps: // LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Traffic footprint characterization of workloads using BPF DTSTART;VALUE=DATE-TIME:20190911T094500Z DTEND;VALUE=DATE-TIME:20190911T103000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Aditi Ghag (VMware)\nApplication workloads are becom ing increasingly diverse in terms of their network resource requirements a nd performance characteristics. As opposed to long running monoliths deplo yed in virtual machines\, containerized workloads can be as short lived as few seconds. Today\, container orchestrators that schedule these workload s primarily consider their CPU and memory resource requirements since they can easily be quantified. However\, network resources characterization is n’t as straight forward. Ineffective scheduling of containerized workloa ds\, which could be throughput intensive or latency sensitive\, can lead t o adverse network performance. Hence\, I propose characterizing and learn ing network footprints of applications running in a cluster\, which can be used while scheduling them in containers/VMs such that their network perf ormance can be improved. \n\nThere is a well-known network issue\, which is achieving low latency for mice flows (those that send relatively small amounts of data) by separating them from the elephant flows (those that se nd a lot of data). I’ve written an eBPF program in C that runs at variou s hook points in the Linux connection tracking (aka conntrack) kernel func tions in order to detect network elephant flow\, and attribute them to the container or VM\, where the flows ingress or egress from. The agent that loads this eBPF program from user space runs in every host in a cluster. I t then feeds this learnt information to a container (or VM) scheduling sys tem such that they can use this information proactively\, while scheduling containerized workloads with light network footprint (e.g.\, microservice s\, functions) and heavy network footprint (e.g.\, data analytics\, data c omputational applications) on the same cluster\, in order to improve their latency and throughput\, respectively. \n\neBPF facilitates running the p rograms with minimal CPU overhead\, in a pluggable\, tunable and safe mann er\, and without having to change any kernel code. It’s also worthwhile to discuss how the workload’s learnt network footprint can be used for d ynamically allocating or tuning Linux network resources like bandwidth\, vcpu/vhost-net allocation\, receive-side scaling (RSS) queue mappings\, et c.\nI'll submit a paper with the (working) source code snippets and detail s if the talk is accepted.\n\n butions/490/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Seamless transparent encryption with BPF and Cilium DTSTART;VALUE=DATE-TIME:20190910T160000Z DTEND;VALUE=DATE-TIME:20190910T164500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: John Fastabend (Isovalent)\nProviding encryption in dynamic environments where nodes are added and removed on-the-fly and serv ices spin-up and are then torn-down frequently\, such as Kubernetes\, has numerous challenges. Cilium\, an open source software package for providin g and transparently securing network connectivity\, leverages BPF and the Linux encryption capabilities to provide L3/L7 encryption and authenticati on at the node and service layers. Giving users the ability to apply encry ption either to entire nodes or on specified services. Once configured thr ough a high level feature flag (--enable-encrypt-l3\, --enable-encrypt-l7) the management is transparent to the user. Cilium will manage and ensure traffic is encrypted allowing for auditing of encrypted/unencrypted flows via a monitoring interface to ensure compliance.\n\nIn this talk we will s how how Cilium accomplishes this in the Linux datapath and control plane. As well as discuss how Cilium with Linux and BPF fits into the evolving en cryption standards and frameworks such as IPsec\, mTLS\, Secure Production Identity Framework For Everyone (SPIFFE)\, and Istio. Looking forward we propose a set of extensions to the Linux kernel\, specifically to the BPF infrastructure\, to ease the adoption and improve the efficiency of these protocols. Specifically\, we will look at a series of BPF helpers\, possib le hardware support\, scaling to thousands of nodes\, and transparently en forcing policy on encrypted sessions.\n\nFinally to show this is not mere slide-ware we will show a demo Cilium implementing transparent encryption. \n\n LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Making Networking Queues a First Class Citizen in the Kernel DTSTART;VALUE=DATE-TIME:20190910T144500Z DTEND;VALUE=DATE-TIME:20190910T153000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Magnus Karlsson (Intel)\, Björn Töpel (Intel)\, Je sper Dangaard Brouer (RedHat)\, Toke Höiland-Jörgensen (RedHat)\, Jakub Kicinski (Netronome)\, Maxim Mikityanskiy (Mellanox)\nXDP (the eXpress Dat a Path) is a new method in Linux to process\npackets at L2 and L3 with rea lly high performance. XDP has already\nbeen deployed for use cases involvi ng ingress packet filtering\, or\ntransmission back through the ingress in terface\, are already well\nsupported today. However\, as we expand the us e cases that involve the\nXDP_REDIRECT action\, e.g.\, to send packets to other devices\, or\nzero-copy them to userspace sockets\, it becomes chall enging to retain\nthe high performance of the simpler operating modes.\n\n One of the keys to get good performance for these advanced use cases\,\nis effective use of dedicated hardware queues (on both Rx and Tx)\, as\nthis makes it possible to split traffic over multiple CPUs\, with no\nsynchron ization overhead in the fast path. The problem with using\nhardware queues like this is that they are a constrained resource\, but\nare hidden from the rest of the kernel: Currently\, each driver\nallocates queues accordin g to its own whims\, and users have little or\nno control over how the que ues are used or configured.\n\nIn this presentation we discuss an abstract ion that makes it possible\nto keep track of queues in a vendor-neutral wa y: We implement a new\nsubmodule in the Linux networking core that drivers can register their\nqueues to. Other pieces of code can then allocate and free individual\nqueues (or sets of them) satisfying certain properties ( e.g.\, "a Tx/Rx\npair"\, or "one queue per core"). This submodule also mak es sure that\nthe queues get IDs that are hardware independent\, so that t hey can\neasily be used by other components. We show how this could be exp osed\nto userspace\, and how it can interact with the existing REDIRECT\np rimitives\, such as device maps.\n\nFinally if there is time\, we would li ke to discuss a related problem:\noften a userspace program wants to expre ss its configuration not in\nterms of queue IDs\, but in terms of a set of packets it wants to\nprocess (e.g.\, by specifying an IP address). So how do we change user\nspace APIs that use queue IDs to be able to use someth ing more\nmeaningful such as properties of the packet flow that a user wan ts? To\nsolve this second problem\, we propose to introduce a new bind opt ion\nin AF_XDP that takes a simple description of the traffic that is\ndes ired (e.g. "VLAN ID 2"\, "IP address fc00:dead:cafe::1"\, or "all\ntraffic on a netdev"). This hides queue IDs from userspace\, but will\nuse the ne w queue logic internally to allocate and configure an\nappropriate queue.\ n\n LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Making the Kubernetes Service Abstraction Scale using eBPF DTSTART;VALUE=DATE-TIME:20190910T140000Z DTEND;VALUE=DATE-TIME:20190910T144500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Borkmann Daniel (Cilium)\, Pumputis Martynas (Cilium )\nIn this talk\, we will present a scalable re-implementation of the Kube rnetes service abstraction with the help of eBPF. We will discuss recent c hanges in the kernel which made the implementation possible\, and some cha nges in the future which would simplify the implementation.\n\nKubernetes is an open-source container orchestration multi-component distributed syst em. It provides mechanisms for deploying\, maintaining and scaling applica tions running in containers across a multi-host cluster. Its smallest sche duling unit is called a pod. A pod consists of multiple co-located contain ers. Each pod has its own network namespace and is addressed by an unique IP address in a cluster. Network connectivity to and among pods is handled by an external plugin.\n\nMultiple pods which provide the same functional ity can be grouped into services. Each service is reachable within a clust er via its virtual IP address allocated by Kubernetes. Also\, a service ca n be exposed to outside of a cluster via the public IP address of a cluste r host IP address and a port which is allocated by Kubernetes. Each reques t sent to a service is load-balanced to any of its pods.\n\nKube-proxy is a Kubernetes component which is responsible for the service abstraction im plementation. The default implementation is based on Netfilter's iptables. For each service and its pods it creates couple rules in the `nat` table which do a load-balancing to pods. For example\, for the "nginx" service which virtual IP address is and which is running two pods wi th IP addresses and the following relevant iptab les rules are created:\n\n\n\n-A KUBE-SERVICES -d -p tcp -m comment --comment "default/nginx: cluster IP" -m tcp --dport 80 -j KUBE -SVC-253L2MOZ6TC5FE7P\n\n-A KUBE-SVC-253L2MOZ6TC5FE7P -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-PCCJCD7AQBIZDZ2N\n-A KUBE-S VC-253L2MOZ6TC5FE7P -j KUBE-SEP-UFVSO22B5A7KHVMO\n\n-A KUBE-SEP-PCCJCD7AQB IZDZ2N -s -j KUBE-MARK-MASQ\n-A KUBE-SEP-PCCJCD7AQBIZDZ2N -p tcp -m tcp -j DNAT --to-destination\n-A KUBE-SEP-UFVSO2 2B5A7KHVMO -s -j KUBE-MARK-MASQ\n-A KUBE-SEP-UFVSO22B5A7KH VMO -p tcp -m tcp -j DNAT --to-destination\n\n\n\nIt has b een demonstrated \\[1\\]\\[2\\]\\[3\\] that kube-proxy due to its foundati onal technologies (Netfilter\, iptables) is one of the major pain points w hen running Kubernetes at large scale from performance\, reliability\, and operations perspective.\n\nCilium is an open-source networking and securi ty plugin for container orchestration systems\, such as Kubernetes. Unlike the majority of such networking plugins\, it heavily relies on eBPF techn ology which lets one to dynamically reprogram the kernel.\n\nThe most rece nt Cilium v1.6 release brings the implementation in eBPF of the Kubernetes service abstraction. This allows one to run a Kubernetes cluster without kube-proxy. Thus\, it makes Kubernetes no longer dependent on Netfilter/ip tables. This improves scalability and reliability of a Kubernetes cluster. \n\nNo Kubernetes knowledge is required. The talk might be relevant for th ose who are interested in container networking with eBPF (loadbalancing\, NAT).\n\n\\[1\\]:\n\\[2\\]:\n \\[3\\]:\n\n ontributions/458/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Future ipv4 unicast extensions DTSTART;VALUE=DATE-TIME:20190910T114500Z DTEND;VALUE=DATE-TIME:20190910T123000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Dave Täht (\nIPv4's success story w as in carrying unicast packets\nworldwide.\nService sites still need IPv4 addresses for everything\,\nsince the majority of Internet client nodes do n't yet\nhave IPv6 addresses. IPv4 addresses now cost 15 to 20\ndollars ap iece (times the size of your network!) and\nthe price is rising.\n\nThe IP v4 address space includes hundreds of millions of\naddresses reserved for obscure (the ranges 0/8\, and\n127/16)\, or obsolete (225/8-231/8) reasons \, or for\n"future use" (240/4 - otherwise known as class E).\nInstead of leaving these IP addresses unused\, we have\nstarted an effort to make the m usable\, generally. This\nwork stalled out 10 years ago\, because IPv6 w as going\nto be universally deployed by now\, and reliance on IPv4\nwas ex pected to be much lower than it in fact still is.\n\nWe have been reportin g bugs and sending patches to\nvarious vendors. For Linux\, we have patche s accepted\nin the kernel and patches pending for the\ndistributions\, rou ting daemons\, and userland tools.\nSlowly but surely\, we are decontamina ting these IP\naddresses so they can be used in the near future.\n\nMany r outers already handle many of these addresses\,\nor can easily be configur ed to do so\, and so we are\nworking to expand unicast treatment of these addresses\nin routers and other OSes. We plan an authorized\nexperiment to route some of these addresses globally\,\nmonitor their reachability from different parts of the\nInternet\, and talk to ISPs who are not yet treat ing\nthem as unicast to update their networks.\n\nWouldn't it be a better world with a few hundred\nmillion more IPv4 addresses in it?\n\nhttps://li LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:netfilter hardware offloads DTSTART;VALUE=DATE-TIME:20190909T160000Z DTEND;VALUE=DATE-TIME:20190909T164500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Pablo Neira ()\nWith the advent of the the flow rule and flow block API\, ethtool_rx\, netfilter and tc can share the same inf rastructure to represent hardware offloads.\n\nThis presentation discusses the reuse of the existing infrastructure originally implemented by tc\, s uch as the netdev_ops->ndo_setup_tc() interface and the TC_SETUP_CLSFLOWER classifier.\n\n LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:LAG and hardware offload to support RDMA and IO virtualized interf aces DTSTART;VALUE=DATE-TIME:20190909T144500Z DTEND;VALUE=DATE-TIME:20190909T153000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Vivek Kashyap (Intel)\, Anjali Singhai Jain (Intel)\ , Piotr Uminski (Intel)\nLink Aggregation (LAG) is traditionally served by bonding driver. Linux bonding driver supports all LAG modes on almost an y LAN drivers - in the software. However modern hardware features like SR- IOV-based virtualization and state full offloads such as RDMA are currentl y not well supported by this model. One of possible options to solve that is to implement LAG functionality entirely in NIC's hardware or firmware. In our presentation we present another approach\, where LAG functionality for state full offloads such as RDMA and IO virtualization is implemented mostly in software\, with very limited support from existing Hardware and firmware. A concept that should make the solution more generic without com plicating the HW any further.\n \nThe presentation is focused on 3 areas: implementation of active-backup mode for RDMA and virtual functions\, usag e of RX hash value to implement flow-based active-active mode and new act ive-active mode for virtual functions.\n \nProposed implementation of the active-backup mode for RDMA is done in RDMA and LAN drivers. An applicatio n continues using direct HW support for RDMA. LAN driver (with the help of RDMA driver) observes notifications from the bonding driver and according ly controls low-level TX scheduling and RX rules for RDMA queues. The same mechanism can be used to transparently redirect network virtual functions from active to backup. We further explore the use of RX hash to implement active-active mode.\n\n s/455/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:XDP bulk packet processing DTSTART;VALUE=DATE-TIME:20190909T140000Z DTEND;VALUE=DATE-TIME:20190909T144500Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Maciej Fijałkowski ()\nIt is well known that batchi ng can often improve software performance. This is\nmainly because it util izes the instruction cache in a more efficient way.\nFrom the networking p erspective\, the size of driver's packet processing\npipeline is larger th an the sizes of instruction caches. Even though NAPI\nbatches packets over the full stack and driver execution\, they are processed\none by one by m any large sub systems in the processing path. Initially this\nwas raised by Jesper Brouer. With Edward Cree's listifying SKBs idea\, the\nfirst imp lementation results look promising. How can we take this a step\nfurther a nd apply this technique to the XDP processing pipeline?\n\nTo do that\, th e proposition is to back down from preparing xdp_buff struct\none-by-one\, passing it to XDP program and then acting on it\, but instead we\nwould p repare in driver an array of XDP buffers to be processed. Then\, we\nwould have only a single call per NAPI budget to XDP program\, which would give \nus back a list of actions that driver needs to take. Furthermore\, the number\nof indirect function calls\, gets reduced\, as driver gets to jite d BPF program\nvia indirect function call.\n\nIn this talk I would like to present the proof-of-concept of described idea\,\nwhich was yielding arou nd 20% better XDP performance for dropping packets with\ntouching headers memory (modified xdp1 from linux kernel's bpf samples).\n\nHowever\, the m ain focus of this presentation should be a discussion about a\nproper\, ge neric implementation\, which should take place after showing out the\nPOC\ , instead of the current POC. I would like to consider implementation\ndet ails\, such as:\n- would it be better to provide an additional BPF verifie r logic\, that when\n properly instrumented (make use of prologue/epilogu e?)\, would emit BPF\ninstructions responsible for looping over XDP progra m\, or should we have the\nloop within the XDP programs?\n- the mentioned POC has a whole new NAPI clean Rx interrupt routine\; what\n should we do to make it more generic in order to make driver changes\n smaller?\n- Ho w about batching the XDP actions? Do all the drops first\, then Tx/redirec t\,\n then the passes. Would that pay off?\n\nhttps://linuxplumbersconf.o rg/event/4/contributions/465/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:Programmable socket lookup with BPF DTSTART;VALUE=DATE-TIME:20190909T114500Z DTEND;VALUE=DATE-TIME:20190909T123000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Jakub Sitnicki (Cloudflare)\, Lorenz Bauer (Cloudfla re)\, Marek Majkowski (Cloudflare)\nAt Netconf 2019 we have presented a BP F-based alternative to steering\npackets into sockets with iptables and TP ROXY extension. A mechanism\nwhich is of interest to us because it allows (1) services to share a\nport number when their IP address ranges don't ov erlap\, and (2) reverse\nproxies to listen on all available port numbers.\ n\nThe solution adds a new BPF program type BPF_INET_LOOKUP\, which is\nin voked during the socket lookup. The BPF program is able to steer SKBs\nby overwriting the key used for listening socket lookup. The attach\npoint is associated with a network namespace.\n\nSince then\, we have been reworki ng the solution to follow the existing\npattern of using maps of socket re ferences for redirecting packets\, that\nis REUSEPORT_SOCKARRAY\, SOCKMAP\ , or XSKMAP. We expect to publish the\nnext version of BPF_INET_LOOKUP RFC patch set\, which addresses the\nfeedback from Netconf\, in August.\n\nDu ring LPC 2019 BPF Microconference we would like to briefly recap on\nhow B PF-driven socket lookup compares to classic bind()-based dispatch\,\nTPROX Y packet steering\, and socket dispatch on TC ingress currently in\ndevelo pment by Cilium.\n\nNext we would like discuss low-level implementation ch allenges. How to\nbest ensure that packet delivery to connected UDP socket s remains\nunaffected? Can a BPF_INET_LOOKUP program co-exist with reusepo rt\ngroups? Is there a possibility of code sharing with REUSEPORT_SOCKARRA Y\nimplementation?\n\nFollowing the implementation discussion\, we will to uch on performance\naspects\, that is what is the observed cost of running BPF during socket\nlookup both in SYN flood and UDP flood scenarios.\n\nF inally\, we want to go into the usability of user-space API. Redirection\n with a BPF map of sockets raises a question who populates the map\, and\ni f existing network applications like NGINX need to be modified in any\nway to receive traffic steered with this new mechanism.\n\nThe desired outcom e of the discussion is to identify steps needed to\ngraduate the patch set from an RFC series to a ready-for-review\nsubmission.\n\nhttps://linuxplu LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT BEGIN:VEVENT SUMMARY:BPF packet capture helpers\, libbpf interfaces DTSTART;VALUE=DATE-TIME:20190909T094500Z DTEND;VALUE=DATE-TIME:20190909T103000Z DTSTAMP;VALUE=DATE-TIME:20200123T213459Z DESCRIPTION:Speakers: Alan Maguire (Oracle)\nPacket capture is useful from a general debugging standpoint\, and is useful in particular in debugging BPF programs that do packet processing. For general debugging\, being abl e to initiate arbitrary packet capture from kprobes and tracepoints is hig hly valuable (e.g. what do the packets that reach kfree_skb() - representi ng error codepaths - look like?). Arbitrary packet capture is distinct fro m the traditional concept of pre-defined hooks\, and gives much more flexi bility in probing system behaviour. For packet-processing BPF programs\, p acket capture can be useful for doing things such as debugging checksum er rors. The intent of this proposal is to help drive discussion around how t o ease use of such features in BPF programs\, namely:\n\n- should addition al BPF helper(s) be provided to format packet data suitable for libpcap in terpretation?\n- should libbpf provide interfaces for retrieving packet ca pture data?\n- should interfaces be provided for pushing filters?\n\nNote that while there has been some work in this area already\, such as \n\nhtt ps://\n\ seems like such efforts woul d be made much simpler if APIs were provided.\n\nhttps://linuxplumbersconf .org/event/4/contributions/489/ LOCATION:Corinthia Hotel Lisbon Floriana/room-I URL: END:VEVENT END:VCALENDAR