Chair of Network Architectures and Services Department of Informatics Technical University of Munich Performance Implications of Packet Filtering with Linux eBPF Dominik Scholz , Daniel Raumer, Paul Emmerich, Alexander Kurtz, Krzysztof Lesiak and Georg Carle Chair of Network Architectures and Services Department of Informatics Technical University of Munich
History of Extended Berkeley Packet Filter (eBPF) Recent Hot Topic • 1992: BPF developed for UNIX • Packet filtering, e.g. tcpdump • 2014: eBPF introduced into Linux Kernel • Network monitoring • Network traffic manipulation • Non-networking purposes Tracing • Security auditing • . . . • • Since then: • Continuous (performance) improvements [1] • “super powers have finally come to Linux” [2] • Offloading support, e.g. Netronome SmartNIC [3] • At Host Dataplane Acceleration Tutorial @ SIGCOMM 2018 [4] [1] A thorough introduction to eBPF, https://lwn.net/Articles/740157/ [2] Brendan Gregg, BPF: Tracing and More, https://www.youtube.com/watch?v=JRFNIKUROPE [3] NetroNews, August 2018, http://hosted.verticalresponse.com/183413/a79f667b58/1413119999/c60e793082/ [4] ACM SIGCOMM 2018 Morning Tutorial on Host Dataplane Acceleration (HDA), https://conferences.sigcomm.org/sigcomm/2018/tutorial-hda.html D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 2
Outline Extended Berkeley Packet Filter Use Case: Packet Filtering Case Study I: eXpress Data Path (XDP) Case Study II: Socket-attached Filtering Conclusion D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 3
Extended Berkeley Packet Filter (eBPF) What is it? • User space program • Run in virtual machine in kernel space (“sandboxed”) • Dynamically interpreted (default) or compiled just-in-time (JIT) Limitations • Static verification • No backward jumps (loops) • Maximum of 4096 instructions � Cannot compromise/block kernel • Data access: key-value stores (maps) • Memory region set up before program is loaded • Key size, value type, max. number of entries predetermined � Secure data access between user space and kernel space D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 4
Study: Packet Filtering Layers of Packet Filters Apps Application level Applications OS Transport prot. System level Network stack Network NAPI level Driver Poll routines NIC Hardware DMA • Hardware offloading and filtering level HW-filter • Dedicated platforms based on FPGAs or SmartNICs � High-performance, ideal for coarse filtering (DoS) D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 5
Study: Packet Filtering Layers of Packet Filters Apps Application level Applications OS Transport prot. System level Network stack • Before network stack processing Network NAPI level � Dropping packets with low overhead in software Driver Poll routines NIC Hardware DMA • Hardware offloading and filtering level HW-filter • Dedicated platforms based on FPGAs or SmartNICs � High-performance, ideal for coarse filtering (DoS) D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 5
Study: Packet Filtering Layers of Packet Filters Apps Application level Applications OS • Hooks into packet processing of network stack Transport prot. • e.g. iptables or nftables System level � Requires root access, system-specific knowledge Network stack • Before network stack processing Network NAPI level � Dropping packets with low overhead in software Driver Poll routines NIC Hardware DMA • Hardware offloading and filtering level HW-filter • Dedicated platforms based on FPGAs or SmartNICs � High-performance, ideal for coarse filtering (DoS) D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 5
Study: Packet Filtering Layers of Packet Filters Apps • Traffic addressed for a specific application Application � Application “knows best”, high penalty for dropping packets level Applications OS • Hooks into packet processing of network stack Transport prot. • e.g. iptables or nftables System level � Requires root access, system-specific knowledge Network stack • Before network stack processing Network NAPI level � Dropping packets with low overhead in software Driver Poll routines NIC Hardware DMA • Hardware offloading and filtering level HW-filter • Dedicated platforms based on FPGAs or SmartNICs � High-performance, ideal for coarse filtering (DoS) D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 5
Use Case: Packet Filtering Common Scenario – State of the Art Apps • Traffic addressed for a specific application Application � Application “knows best”, high penalty for dropping packets level Applications OS • Hooks into packet processing of network stack Transport prot. Centralized Firewall • e.g. iptables or nftables System e.g. iptables, nftables level � Requires root access, system-specific knowledge Network stack • Before network stack processing Network NAPI level � Dropping packets with low overhead in software Driver Poll routines NIC Hardware DMA • Hardware offloading and filtering level HW-filter • Dedicated platforms based on FPGAs or SmartNICs � High-performance, ideal for coarse filtering (DoS) D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 6
Use Case: Packet Filtering Performance Baseline Packets [Mpps] 1 . 5 Processed nftables iptables 1 0 . 5 0 16 32 64 128 256 512 Number of Rules [#] Maximum packet rate D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 7
Use Case: Packet Filtering Performance Baseline Relative Probability [%] 40 nftables 20 0 Packets [Mpps] 1 . 5 40 Processed nftables iptables iptables 1 20 0 . 5 0 40 0 No Firewall 16 32 64 128 256 512 20 Number of Rules [#] 0 20 40 60 80 100 120 140 160 180 200 Maximum packet rate Latency [ µ s] Latency distribution at 0.03 Mpps D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 7
Use Case: Packet Filtering Performance Baseline Relative Probability [%] 40 nftables 20 0 Packets [Mpps] 1 . 5 40 Processed nftables iptables iptables 1 20 0 . 5 0 40 0 No Firewall 16 32 64 128 256 512 20 Number of Rules [#] 0 20 40 60 80 100 120 140 160 180 200 Maximum packet rate Latency [ µ s] Latency distribution at 0.03 Mpps Performance sufficient for today’s applications? Limitations: Centralized, complex ruleset, requiring root access D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 7
Use Case: Packet Filtering (using Commodity Hardware) Possibilities with eBPF Apps Application FWs Application FWs Applications Application level Application FWs OS Transport prot. eXpress Data Path System level Network stack • First line of defense • Coarse but efficient filtering XDP Network NAPI � Protection against DoS attacks level Driver Poll routines NIC Hardware DMA level HW-filter D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 8
Case Study I: eXpress Data Path (XDP) Overview Source: https://www.iovisor.org/technology/xdp D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 9
Case Study I: eXpress Data Path (XDP) Measurement Setup ◭ ◭ XDP LoadGen ◮ ◮ • XDP program: • Drop if port is blacklisted • Otherwise, forward to outgoing interface � Excludes network stack • Load generator: • MoonGen [7] • Generates n UDP flows • Just-in-time compiler enabled • Traffic pinned to single core • Hyper-threading and Turbo Boost disabled [7] https://github.com/emmericp/MoonGen D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 10
Case Study I: eXpress Data Path (XDP) Performance Baseline 15 Processed Packets 10GbE line-rate 90% dropped 50% dropped 10% dropped 10 [Mpps] 5 0 0 2 4 6 8 10 12 14 Offered Rate [Mpps] Packet filtering performance • Drop everything: 10 Mpps • Drop x-Percent: 6.4 Mpps to 7.2 Mpps D. Scholz, D. Raumer, P . Emmerich, A. Kurtz, K. Lesiak, G. Carle — Performance Implications of Packet Filtering with Linux eBPF 11
Recommend
More recommend
