- people - netdevconf.info

0x16 talk, XPU interaction with the Linux kernel network
by Jamal Hadi Salim 02 Oct '22

02 Oct '22

xPUs[1] have emerged as a way to address host CPU capacity being unable to keep up with link speed growths (1-400 gpbs is here and 1Tbps is coming). Two talks cover xPU interaction with the Linux network stack. Both illustrate offloading of the kernel's VxLAN, L2 forward and routing tables. The first talk, by Sandeep Nagapattinam et al, highlights an abstraction using P4 mapped to OVS. Offloading is done on the Intel Mount Evans IPU[2]. https://netdevconf.info/0x16/session.html?Linux-kernel-networking-accelerat… The second talk, by Alexander Petrovskiy et al, covers a use case of accelerating L3 E-VPN exposing using the kernel tc flower offload mechanism and FRR for BGP distribution. Offloading is done on the Nvidia BlueField DPU[3]. More Details: https://netdevconf.info/0x16/session.html?Towards-a-layer%E2%80%933-data%E2… cheers, jamal [1] XPU is a generalization of what some in the market refer to as a DPU(Data Processing Unit) and others refer to as IPU (Infrastructure Processing Unit). [2]https://www.intel.com/content/www/us/en/products/network-io/infrastructur… [3]https://www.nvidia.com/en-us/networking/products/data-processing-unit/

1 0

ox16 talk, Towards µs Tail Latency and Terabit Ethernet: Disaggregating the Host Network Stack
by Jamal Hadi Salim 02 Oct '22

02 Oct '22

The network stack, from the very first incarnation has offered applications the same "pipe" abstraction; each app writes to a (sender-side) socket "pipe" and the network stack delivers to the receiver side via the NIC queues("pipes") and on the receiver side we have the driver queue(another "pipe") leading to an application "pipe" (socket interface). These pipes are then tied to compute cores which due to their vertical nature cant scale as IO becomes demanding. 100gbps clearly exposes this problem, 400gbps is already being deployed and terabit is on its way. Qizhe Cai et al performed experiments tying cores for network and application processing and assesed applications with long flows and others which are characterized by short flows; in the former the measurements show the bottleneck is the application interfacing compute core (copies etc become dominant) and in the later it is the network processing core (packet/sec is dominant). To resolve these new challenges Qizhe Cai et al introduce NetChannel which hopes to lay the intellectual foundation for a rearchitecture of the kernel network stack. NetChannel disaggregates the tightly-integrated packet processing "pipeline" in today's kernel network stack into layers each of which can be horizontally scaled by throwing more compute or IO/queues on as need basis. More details: https://netdevconf.info/0x16/session.html?Towards-%C2%B5s-Tail-Latency-and-… For netchannel kernel code, see: https://github.com/Terabit-Ethernet/NetChannel cheers, jamal

1 0

0x16 talk: The Anatomy of Networking in High Frequency Trading
by Jamal Hadi Salim 30 Sep '22

30 Sep '22

High Frequency Trading (HFT) demands that transaction latency is paramount when interfacing with the market exchanges. In this talk, PJ Waskiewicz is going to highlight where the Linux kernel networking stack intersects with requirements for HFT, and where it does not. PJ will also expand on how latency and jitter within HFT systems compared to “traditional” networking environments. PJ hopes this talk will generate discussion where HFT networking needs can help to improve the existing intersection points in the kernel, and discuss where further kernel native integration could be achieved. cheers, jamal PS: ReelCheep early bird is still open for two more days: https://netdevconf.info/0x16/registration.html

1 0

0x16 talk: Merging the Networking Worlds
by Jamal Hadi Salim 29 Sep '22

29 Sep '22

BSD socket APIs are entrenched into the networking world and have a universal usability appeal due to their simplicity. Unfortunately, if you care about high end performance then, the current BSD socket APIs for sending and receiving data have too much many hazards that hamper performance. These hazards range (to name the most common) from construct such as system calls, memcpy, page reference counting, etc. The impact of these "included" costs severely limit the data rate. Bad enough that modern applications for high performance networking have universally turned towards RDMA and infiniband after declaring TCP/IP as too slow and inefficient! In the pursuit for performance happyness, David Ahern and Shrijeet Mukherjee have explored a few options out there for Linux. They have looked at io_uring, AF_XDP sockets, and RDMA/Infiniband verbs. In this talk they discuss a proposal to merge some concepts of RDMA with traditional TCP/IP networking. Specifically, the ability to create and manage memory regions between processes and hardware along with userspace access to hardware queues and software queues to a kernel driver for submitting work and getting completions. cheers, jamal

1 0

0x16: workshop, Infrastructure datapath function(IDPF)
by Jamal Hadi Salim 29 Sep '22

29 Sep '22

Anjali Singhai Jain, Willem de Bruijin, Sridhar Samudrala, and C. Xia will co-chair a discussion on Infrastructure datapath function(IDPF). Infrastructure datapath function(IDPF) is a vendor neutral datapath function that provides standard host networking interfaces for hosts, containers and guests. These interfaces are exposed, controlled and configured by an infrastructure control plane. The plan is to make IDPF an Open standard by submitting drivers for the Interface to Linux upstream community, to Linux user space community along with software emulated device for IDPF and have the specification ratified by going through a standards process via Oasis technical steering committee. IDPF supports core networking features including multiple tx/rx queues, stateless offloads like checksum offload, Large Segmentation Offload, Receive Side Scaling, Jumbo frames, RX Header Split, Receive side coalescing, vlan strip/insertion etc. The capabilities supported are negotiated with a control plane before exposing to the end user. The driver is designed to work with more or less of these offloads enabled by the device and can accommodate advanced offloads that can be added and negotiated as the device becomes more powerful. Some of the advanced offloads that IDPF can also negotiate are PTP, Packet pacing, Inline IPsec etc. Anjali, Willem, Sridhar and Chenbo will lead a discussion on the motivation and the need for a standard datapath high performance network interface that works across vendors. A WAG agenda includes discussions on: 1) The capability negotiation process, 2) Features supported 3) Plans for upstreaming and standardization of drivers and interface. 4) emulated IDPF devices and IDPF back-ends for simulation of new hardware features, multi-vendor environment deployment, live upgrade of software (driver)/firmware/hardware of IDPF devices, etc More details: https://netdevconf.info/0x16/session.html?Infrastructure-datapath-function(… cheers, jamal

1 0

0x16 talk: HomaLS: Tunneling messages through secure segments
by Jamal Hadi Salim 28 Sep '22

28 Sep '22

In this talk Tianyi Gao and Michio Honda introduce HomaLS, a transport-level encryption integrated with the Homa transport protocol[keynote]. Homa outperforms DCTP by a large margin. It seems natural to use TLS over Homa for secure communication; however, that approach introduces the same challenge as TLS over TCP, that is, to prevent the application from using transparent, opportunistic NIC offloading as is achieved by kTLS today. HomaLS instead allows applications to read or write plain-text data then it performs segment-level encryption taking advantage of Homa utilizing TSO by overlaying the TCP header including the TCP options space. In this talk Tianyi and Michio first present their initial protocol design and then go over their implementation. Since utilizing hardware offloading is crucial, they test whether hardware TLS offloading, which is far more complicated than TSO, works for a Homa segment, which has a different protocol number than TCP in the IPv4 header. They examined the Nvidia ConnectX-6 DX NIC, and found that it works with minor driver modifications, indicating the viability of the HomaLS offload approach. They will finally present experimental results. Their prototype implementation that encrypts data in software confirms that HomaLS exhibits shorter RTT than kTLS over TCP by 26–30%, achieving 18–23µs of message RTT. References --------- Keynote: https://netdevconf.info/0x16/session.html?keynote-ousterhout cheers, jamal

1 0

0x16 talk: Your Network Datapath Will Be P4 Scripted
by Jamal Hadi Salim 28 Sep '22

28 Sep '22

P4 has gained industry-wide acceptance as a datapath language. Infact big customers who are consumers of xPUs, example MS[7], are requesting that NIC vendors to allow prescription of required datapaths using P4[1]. IOW, P4 is now a big deal. Running P4 on top of TC has been a subject of many many discussions in the community over the last few years, initially in informal physical and electronic hallways and eventually in physical formal meetings, see [1],[2],[3],[4],[5],[6]. Finally, some action. In this talk J. Hadi Salim et al will discuss the overall design and architecture of P4TC with a focus on scriptable software and hardware offloaded dataplanes via TC. "Scriptability" as a concept has precedence in the kernel TC architecture in the u32 classifier, the pedit action, etc. P4TC builds on that knowledge and allows templating of a specific datapath. A P4 program when compiled generates tc scripts, which when executed, manifests into the functionally equivalent P4 program in the kernel as is in hardware. In the simple cases a P4 compiler is not needed since the TC scripts can be handcoded. "Scriptability" means ability to manifest _any_ P4 program regardless of functionality into the kernel without compiling any kernel code or loading any binary blobs into the kernel. P4TC takes advantage of the modularity of the TC architecture and makes very minimal changes to the TC core code while providing all the necessary objects to sufficiently abstract a P4 program. The first version of the code is expected to be released at the conference during this talk. References: ---------------- [1] Matty Kadosh, "P4 Offload", TC Workshop, Netdev conference 2.2, 2017 https://legacy.netdevconf.info/2.2/slides/salim-tc-workshop04.pdf [2] Prem Jonnalagadda, "Mapping tc to P4", TC Workshop, Netdev conference 2.2, 2017 https://legacy.netdevconf.info/2.2/slides/salim-tc-workshop06.pdf [3] Jamal Hadi Salim, "What P4 Can Learn From Linux Traffic Control", proceedings of ONF 5th P4 Workshop, 2018 https://opennetworking.org/wp-content/uploads/2020/12/Jamal_Salim.pdf [4] Many speakers, TC P4 workshop, Intel, Santa Clara, 2018 https://files.netdevconf.info/d/5aa8c0ca61ea4e96bb46/ [5] Antonin Bas and R. Krishnamoorthy. "Instrumenting P4 in the Kernel", TC Workshop, Netdev conference 0x12, 2018 https://www.files.netdevconf.info/d/9535fba900604dcd9c93/files/?p=/Instrume… [6] Marian Pritsak and Matty Kadosh, "P4 Compiler Backend for TC", Netdev conference 0x13, 2019 https://legacy.netdevconf.info/0x13/session.html?p4-compiler-backend-for-tc [7] MS Azure DASH https://github.com/Azure/DASH/tree/main/documentation

1 0

0x16 talk: NVMeTCP Offload – Implementation and Performance Gains
by Jamal Hadi Salim 27 Sep '22

27 Sep '22

Shai Malin and Aurelien Aptel build up on the work presented At netdev conf 0x15[1] to define the concept of ULP (upper layer protocol) DDP (direct data placement). The idea is to provide request-response ULP protocols, such as NVMe-TCP, the ability to place response data directly in pre-registered buffers according to protocol header tags. For NVMe-TCP, on the receive side two things happen: 1) The NIC places data directly onto the user space provided buffers totally eliminating data copy between kernel TCP socket layer and user space. 2) The NIC computes and validates CRCs - a compute intensive operation further saving host compute resources. On the transmit path the CRC calculation is offloaded. All this is done with very minimal changes to the core kernel TCP! In this talk, Shai and Aurelien will present the NVMeTCP DDP and CRC (data digest) offload design and the associated driver-HW interaction that makes it work. They will present the performance benefit of the offload in a variety of comparisons and under different conditions. They will also cover the challenges we had and how they were able to resolve them. [1]https://netdevconf.info/0x15/session.html?Autonomous-NVMe-TCP-offload cheers, jamal PS: Yes, early bird registration, which is ReelCheep, is still open. Visit https://netdevconf.info/0x16/registration.html

1 0

0x16, talk: State Of The Union In TCP Land
by Jamal Hadi Salim 26 Sep '22

26 Sep '22

Eric Dumazet, who doesnt do much talking (rumor is that is the way of network ninjas), will give us a state of the union of both user space and kernel realms of the TCP universe. cheers, jamal Another reminder that the early bird registration is still open and reelcheep https://netdevconf.info/0x16/registration.html

1 0

0x16, talk: Pushing OpenVPN down the stack: Data Channel Offload (DCO)
by Jamal Hadi Salim 26 Sep '22

26 Sep '22

OpenVPN is probably the most ubiquitous VPN software in the open source realm - multiplexing created SSL tunnels over TCP/UDP. Upto now both the control and the data planes were implemented in userspace - which has limited scaling capacity. In this talk Antonio Quartulli describes, what he calls the OpenVPN Data Channel Offload (ovpn-dco for brevity), the offloading of the OpenVPN datapath to the kernel. Antonio will discuss the netlink control plane interface, implementation and performance results. cheers, jamal PS: Reminder, early bird registration - reelcheep is still open https://netdevconf.info/0x16/registration.html

1 0

2024

2023

2022

2021

2020

2019

2018

people