- people - netdevconf.info

0x17: Talk, Scripting the Linux Routing Table with Lua
by Jamal Hadi Salim 06 Oct '23

06 Oct '23

You can run Lua scripts inside the kernel using the Lunatik project! Lunatik has been previously used for scripting Netfilter and XDP subsystems, allowing users to create complex network filters using Lua. For instance, it has been used for filtering L7 traffic such as HTTP and HTTPS inside the kernel. In this talk, Lourival Vieira Neto, Marcel Moura, Ana Lúcia de Moura and Roberto Ierusalimschy present the evolution of this framework and illustrate a sample use case implementing a kernel-level adaptive routing service. This service allows the system to monitor the reliability of a network route and adjust its routing table dynamically in case of failure. For instance, a home router might use such service to fall back to the cellular network using a mobile phone as a gateway. Lourival et al also spice this service up by implementing a protocol that allows nodes to advertise themselves as alternative gateways and for the router to notify nodes when elected as the new gateway. Lourival et al will describe the kernel details and associate infrastructure interaction ( netdevice notification chain, kthread, socket, RCU and FIB, etc). cheers, jamal

1 0

0x17: Talk, eBPF Qdisc: a generic building block for traffic control
by Jamal Hadi Salim 06 Oct '23

06 Oct '23

Adding a new packet scheduling algorithm in the kernel requires implementing a Qdisc kernel module - which could be cumbersome. Writing a custom scheduling algorithm which may not make sense for the rest of the community is frowned upon. On top of Qdiscs, different classifiers and rules can be applied to packets as well, which further complicates the combination of choices. Amery Hung and Cong Wang introduce eBPF Qdisc, a fully programmable Qdisc with eBPF. Amery and Cong believe that the approach they are taking will provide developers not only a more flexible and safer way to implement packet schedulers, but also orchestrating packets in coordination with other networking components. In this talk, they first show that eBPF Qdisc is capable of realizing a sophisticated Qdisc by implementing fair queueing (fq) Qdisc. Then, they evaluate the performance of the fq against the existing fq in the Linux kernel. Finally, they will show how eBPF Qdisc can help developers implement Qdisc's with diverse functionalities through two use cases: 1) we build a more robust earliest departure time (EDT) rate limiter by coordinating with a fq Qdisc through eBPF maps and 2) show eBPF Qdisc as a flexible way to create network emulators. cheers, jamal

1 0

0x17 Talk, Leveraging Homa: Enhancing Datacenter RPC Transport Protocols
by Jamal Hadi Salim 06 Oct '23

06 Oct '23

Hyper-scale data centers, such as Bytedance, have a strong need for optimal RPC performance. Homa is purpose-built for RPCs making it ideal for such environments. In this talk, Xiaochun Lu and Zijian Zhang do a comparative study of gRPC's performance on Homa versus over TCP. They observe clear performance advantages in favor of Homa, especially for RPC messages under 50KB, in terms of both latency and throughput. Like John's talk[1], they optimize longer RPC messages and improve bidirectional messaging. Xiaochun and Zijian will further provide performance insights, describe their mods to the Homa kernel code, and guide participants through the tangible benefits of integrating Homa into their RPC transport framework. [1]https://netdevconf.info/0x17/sessions/talk/kernel-managed-user-buffers-in-homa.html cheers, jamal

1 0

0x17: Talk, Kernel-Managed User Buffers in Homa
by Jamal Hadi Salim 06 Oct '23

06 Oct '23

Reminder: One more day to go for early bird registration.. Homa was first introduced to us in John Ousterhout's exciting 0x16 keynote[1]. John argued in the keynote that it was time to replace TCP with Homa to avoid what he labelled as the "datacentre tax". For the uninformed: Homa is message-oriented like UDP or SCTP as opposed to TCP being stream-oriented. There is no notion of connection in Homa, only request/response RPC messaging. A single Homa socket can send/receive RPCs to many peers. One advantage that TCP has by virtue of using the streaming approach is it can pipeline very large messages (think 500KB across MTU sized packets on the wire) - whereas a message oriented approach will have to copy bytes to/from user space and DMA-able packet buffers in parrallel. In his experiments with an mlx5 based 25G NIC, Dr. Ousterhout found that TCP infact outperformed Homa with large messages. At 500KB message size TCP was able to achieve 17-19 Gbps throughput, Homa was only able to hit 10-11Gbps. How dare TCP beat Homa in any metric! So John set out to fix this situation ;->. When he was done with the preliminary work Homa was able to hit the same rate as TCP (17-19Gbps). In this talk, he will go over the approach he took in the kernel code to allow the kernel to manage user mmaped buffers, changes made to both recvmsg() and sendmsg() to make this happen. 1. https://netdevconf.info/0x16/sessions/keynote/keynote-ousterhout.html cheers, jamal

1 0

0x17: Talk, Zero Copy Receive using io_uring
by Jamal Hadi Salim 05 Oct '23

05 Oct '23

The war on memory bottlenecks[1][2] continues with this talk from David Wei and Pavel Begunkov. Socket recv() data is first copied/DMAed into the kernel memory and then again into user space memory - adding pressure to overall memory bandwidth and of course comes with a CPU cost. While there are other approaches to avoid the second copy on recv() such as DPDK, RDMA etc, David and Pavel argue that all of them have downsides - ranging from being proprietary, custom patched drivers, and difficult to debug and worse requiring a rewrite of the applications... Our esteemed speakers instead opt for continuing to use the network stack as is and io_uring as the user facing API. So what do we need to get this working? As in [2] that the NIC supports header splitting and RSS flow steering. On incoming data the headers traverse the TCP stack while data is DMA'ed not to the kernel memory but into user space... David and Pavel will discuss the overall approach they took and describe in some detail the kernel infra as well as what uapi would look like. They will further review kernel-existing zero copy approaches and how they plan to coexist with them. Last but not least they will dig into limitations and challenges of zero copy receive and how they overcome them to facilitate a real deployment. [1] https://netdevconf.info/0x17/sessions/talk/congestion-control-architecture-… [2] https://netdevconf.info/0x17/sessions/talk/device-memory-tcp.html cheers, jamal Reminder: 2 more days to go for early bird registration

1 0

0x17: Talk, Device Memory TCP
by Jamal Hadi Salim 05 Oct '23

05 Oct '23

My apologies for putting some marketing at the top of this email: Reminder, Early bird ticketing is open for 2 more days; the sooner you register the better it is for our planning... And now to tell you about one of my favorite talks this time.. ML/AI continues to be an inspiration for new Linux kernel infrastructure and a theme at netdev conf 0x17! There are a couple of patterns in ML traffic that inspire this work from Mina Almasry, Willem de Bruijn, Eric Dumazet and Kaiyuan Zhang: 1) There is _a lot of freaking data_ being transferred across the network - and it continues to increase dramatically (ex: to accommodate such large data transfers NICs with 800 Gps ports are starting to appear) and 2) The vast majority of this data is typically from a device(eg storage) to another device (eg GPU). For context, assume a scenario where data transfers from SSDs on machineA cross the network to GPUs on machineB; and on machine B: In the rx direction incoming data into the NIC goes to host memory, then from host memory to the GPU. In the tx direction outgoing data goes from GPU to host then out to the NIC. This data movement approach, with multiple round trips across the memory and PCIe busses, is no longer tenable at such large amounts of data quantity. Current host hardware is just not equipped to deal with this. While such bulk transfers amount to low packets/sec rates, you are simply not going to be able to achieve wire speed because of the PCIe and memory bandwith abuse from the multiple round trips (see talk [1] which delves into host limitations). Almasry et al introduce Device Memory TCP to solve these challenges. They implement socket API to enable a user to send directly from device memory (GPU in machineB above example or SSD in machineA) across the network - as well as be able to place incoming data directly in the device memory (GPU in machineB example). How does this magic happen? Well, we need some support from the NIC to split the header on rx such that the TCP headers go to the host and the rest of the data goes directly to the device. The reverse is true for tx direction. Packet headers get to go to stack and get processed in the standard (TCP) code path. Memory bandwidth use is cut dramatically and because NIC to device transfers now happen at the lowest level of the PCIe tree hierarchy PCIe bandwidth use is also cut down dramatically. With devmem TCP, Almasry et al with a setup of 4 machines of GPU+100Gbps NICs - and data sent and received directly from/to device memory - were able to reach ~96.6% line rate speeds. In the talk they will go over details of the kernel/uapi changes to achieve devmem TCP. cheers, jamal [1] https://netdevconf.info/0x17/sessions/talk/congestion-control-architecture-…

1 0

0x17: Talk, Lightweight Implementation of Per-packet Service Protection
by Jamal Hadi Salim 04 Oct '23

04 Oct '23

There are applications which MUST have reliable communication otherwise things fall apart! Think industrial automation, robotics, aerospace, automotive... Failure in timeliness of message delivery could be catastrophic. Typically when such a network is built, the operator makes sure that any congestion-related issues and packet losses are avoided. However, Murphy's law applies: the wiring may break, a radio link can be temporarily shielded by an obstacle, or worse the network nodes can be damaged... To deal with such losses, industry standardization has been introduced to provide per-packet service protection - these include Frame Replication and Elimination for Reliability(FRER) for Layer 2 Ethernet networks and the Packet Replication, Elimination, and OrderingFunctions(PREOF) forLayer3 IP/MPLS networks. Ferenc Fejes et al have implemented FRER in two different approaches: 1) in eBPF/XDP as a lightweight software implementation; and (2) in userspace using PF_PACKET. Ferenc et al will go over the architecture details of the two approaches and then evaluate XDP FRER via an experimental analysis and further compare the two FRER implementations. cheers, jamal Reminder: Three days to go before early-bird registration ends!

1 0

0x17: Talk, Synce4l: open-source implementation of Synchronous Ethernet
by Jamal Hadi Salim 04 Oct '23

04 Oct '23

Almost _a quarter_ of the world-wide consumer Internet traffic is pushed through mobile networks! Wireless mobile network traffic requires tight time synchronization with wired components of the 5G/6G network. PTP with its sub-microsecond synchronization just doesnt cut it anymore and Michał Michalik and Arkadiusz Kubalewski say we need sub-nanosecond synchronization! The only way we can achieve this is to use Synchronous Ethernet (SyncE) which allows transport of clock signals through the Ethernet physical layer. This prevents the clock skew and clock jitter between adjacent network nodes. In this talk, Michał and Arkadiusz will motivate us with the need of frequency synchronization and its role when coupled with PTP in 5G/6G networks. They will discuss the open-source project synce4l [0] and demonstrate, focusing mainly on the features, requirements (both in software and hardware), and configuration in a real network. Finally, the talk will describe how synce4l corresponds with the currently discussed new DPLL (Digital Phase Locked Loop) subsystem [1] in the Linux kernel and user-space networking community. [0] https://github.com/intel/synce4l [1] https://lore.kernel.org/netdev/20230824213132.827338-1-vadim.fedorenko@linu… cheers, jamal Reminder: Three days to go before early-bird registration ends!

1 0

0x17: Talk, Unstoppable Session Layer
by Jamal Hadi Salim 04 Oct '23

04 Oct '23

Back in circa 0x15[0], Alex Aring asked if you have an ECONNRESET on your socket, and even recovered, should we consider the communication reliable? Back then Alex made the argument that when an application encounters connection errors, the act of merely reconnecting reduces the likelihood of the application being considered reliable. He suggested a session layer to help in improving the reliability. To build up on that experience, Alex is back with what he calls "Unstoppable Session Layer" (USL) to allow you to easily switch your networking application to provide a session layer between application and transport layer. This talk will show how to easily put such a session layer on your networking application. It will be demonstrated by a basic TCP ping-pong application while tcpkill [1] tries to run crazy and interfere with the TCP application by sending TCP resets. The eventual goal is to port this implementation into the kernel so that that applications can benefit from it. [0] https://netdevconf.info/0x15/session.html?ECONNRESET-on-a-reliable-socket-a… [1] https://en.wikipedia.org/wiki/Tcpkill cheers, jamal Reminder: Three days to go before early-bird registration ends!

1 0

0x17: talk, Using eBPF to inject IPv6 Extension Headers
by Jamal Hadi Salim 04 Oct '23

04 Oct '23

IPv6 Extension Headers (EH) allows the IPv6 to be more flexible and extensible. Justin Iurman et al say, unfortunately, the EH does not survive easily on the global internet and it is often tricky to analyze these losses without real deployment; and for this reason they built an eBPF instrumented tool based that operators can use to test the survivability of specific IPv6 EHs. The tool can inject any of the extension headers (Hop-by-Hop Options Header, Destination Options Header, Routing Header, the Fragment Header, etc). The talk will go into the details of both the kernel and user space architecture and code of the tool. Justin will further demonstrate its potential usage through a use case deployed by a network service provider. cheers, jamal Reminder: Three days to go before early-bird registration ends!

1 0

0x17: talk, Quantum-Proofing Data: The Power Of Post-Quantum Cryptography
by Jamal Hadi Salim 04 Oct '23

04 Oct '23

Quantum computing presents a potential threat of being able to compromise existing cryptographic techniques. Shor's algorithm has the potential to break the RSA and Elliptic Curve Diffie-Hellman algorithms, both of which are pivotal for key exchange in Transport Layer Security (TLS). Our speaker, Milena Olech, says the solution is to adopt post-quantum cryptography (PQC) algorithms. In this talk Milena outlines the mathematical foundation of the CRYSTALS-Kyber algorithm and illustrates its application in the TLS handshake. In order to assess the efficacy of PQC, Milena will detail a comprehensive comparison between traditional cryptographic methods and post-quantum alternatives and provide a condensed summary of the comparison. cheers, jamal Reminder: Three days to go before early-bird registration ends!

1 0

Register now please!
by Jamal Hadi Salim 03 Oct '23

03 Oct '23

Just a reminder 5 more days to go for early bird registration. Also a reminder this is a hybrid conference; nothing can beat physical get together but you can participate virtually as well. Early registration helps us plan better. See: https://netdevconf.info/0x17/pages/registration.html cheers, jamal

1 0

0x17: talk, Integrating eBPF Into The P4TC Datapath
by Jamal Hadi Salim 03 Oct '23

03 Oct '23

P4TC was first introduced in 0x16[1]. After the first RFC was posted on the list, some of the community feedback made was to convert the s/w datapath from a scriptable (ala tc u32) to instead make use of eBPF with a strong argument being made that the s/w data path will be more performant. In this talk Jamal Hadi Salim et al will discuss the new architecture which factors in eBPF as the software datapath. The talk will go into the P4TC architecture factoring in eBPF and the pros and cons of this change from a scriptable approach. Jamal (twit that horn here) will further discuss the uapi and the kernel code architecture. There have been several RFC postings in the last 9 months[2] and it is expected the upstreaming efforts will start in the near future. cheers, jamal [1]https://netdevconf.info/0x16/session.html?Your-Network-Datapath-Will-Be-P4-Scripted [2] latest at this posting can be found here: https://lore.kernel.org/netdev/20230930143542.101000-1-jhs@mojatatu.com/

1 0

0x17: talk, Firewall and Service Tickets (FAST)
by Jamal Hadi Salim 02 Oct '23

02 Oct '23

There is no good standardized way for applications to signal the network for services, like QoS, that the app wants applied to their packets. Typically it is some sys admin that decides how these services and resources are partitioned and configures their control. Enter FAST - which is being developed at the IETF. Tom Herbert says FAST is secure, expressive, stateless, not spoofable, deployable, efficient, dynamic, requires no DPI, doesn’t disclose internals of the network, and works with any transport protocol. FAST tickets are attached to packets to describe the service requests and grants of admission that the application has requested from the network. Tickets are sent in IPv6 Hop-by-Hop options. Tom will provide rationale why Hop-by-Hop options are really the best choice compared to proposed alternatives despite concerns about them being dropped in the Internet. Eventually Tom will present the kernel patches and tie them to how applications will use the provided infra to request for tickets and how they are granted, how they're set and transmitted in packets, how a network node can process the FAST ticket in the packet and apply network mechanisms to satisfy the service requests. cheers, jamal PS: 5 more days left for early-bird registration. visit netdevconf.info/0x17/registration

1 0

[RESEND]0x17: Talk, Congestion control architecture for host congestion
by Jamal Hadi Salim 02 Oct '23

02 Oct '23

Apologies, I left out the subject line in the last email, so resending this... Link speeds are going up at an incredible rate. Cloud vendors are already asking for 4-800Gbps. Unfortunately the rest of the host hardware infra is not keeping up. Even at the "low low speed;->" of 100Gbps the host CPU speeds, cache sizes, memory access latency, memory bandwidth per core, NIC buffer sizes, are just overwhelmed. As an example 6 CPU cores can saturate all available memory bandwidth - imagine being on a machine that has 56C(112 hyperthreads).... In this talk, Saksham Agarwal, Arvind Krishnamurthy and Rachit Agarwal say that this has brought in new trends not seen before: congestion within the processor, memory and peripheral interconnects of the host which of course causes back pressure all the way to the NIC - meaning back to the network and, alas, causes congestion within the network. Testing with Linux DCTCP shows that host congestion by our speakers found as much as 1% packet drops at the host, 35-55% throughput degradation, and 120-5000x tail latency inflation! Agarwal et al want us to look closely at more than just network heuristics to resolve this emerging challenge. As an example: applications generating CPU-to-memory traffic and clogging the memory bus are currently not considered as part of the congestion control calculus at all - even though they are most certainly part of the culprits. In this talk our esteemed speakers introduce what they call "hostcc" as a response to these challenges. Hostcc makes about ~800 line kernel code changes. A little bit more details: https://netdevconf.info/0x17/6 For the real meat-and-potatoes come to the talk of course! cheers, jamal PS: 5 more days left for early-bird registration. visit netdevconf.info/0x17/registration

1 0

0x17: Talk,
by Jamal Hadi Salim 02 Oct '23

02 Oct '23

Link speeds are going up at an incredible rate. Cloud vendors are already asking for 4-800Gbps. Unfortunately the rest of the host hardware infra is not keeping up. Even at the "low low speed;->" of 100Gbps the host CPU speeds, cache sizes, memory access latency, memory bandwidth per core, NIC buffer sizes, are just overwhelmed. As an example 6 CPU cores can saturate all available memory bandwidth - imagine being on a machine that has 56C(112 hyperthreads).... In this talk, Saksham Agarwal, Arvind Krishnamurthy and Rachit Agarwal say that this has brought in new trends not seen before: congestion within the processor, memory and peripheral interconnects of the host which of course causes back pressure all the way to the NIC - meaning back to the network and, alas, causes congestion within the network. Testing with Linux DCTCP shows that host congestion by our speakers found as much as 1% packet drops at the host, 35-55% throughput degradation, and 120-5000x tail latency inflation! Agarwal et al want us to look closely at more than just network heuristics to resolve this emerging challenge. As an example: applications generating CPU-to-memory traffic and clogging the memory bus are currently not considered as part of the congestion control calculus at all - even though they are most certainly part of the culprits. In this talk our esteemed speakers introduce what they call "hostcc" as a response to these challenges. Hostcc makes about ~800 line kernel code changes. A little bit more details: https://netdevconf.info/0x17/6 For the real meat-and-potatoes come to the talk of course! cheers, jamal PS: 5 more days left for early-bird registration. visit netdevconf.info/0x17/registration

1 0

0x17: Talk, NIC offloads at Hyperscale: experience, new offloads and validation
by Jamal Hadi Salim 01 Oct '23

01 Oct '23

Willem de Bruijn says that lack of clear operating conditions, vague feature definitions and dearth of publicly available tests makes it hard to deploy at scale NIC offloads from multiple vendors. Issues seen in deployments range from inconsistency between devices, scalability limits, incompatibility with real production workloads, and simply hardware bugs; even a commodity offload as a checksum is not as well defined if you look across multiple vendor implementations. Willem will discuss why providing a way to define these offloads precisely, in a way that scales and avoids common bugs, while combining expertise from multiple vendors and users is the way to go. More importantly he believes that sharing all those details in an open and unencumbered format would help alleviate if not solve the current wild-west approach. The effort is currently housed under the auspices of the "OCP NIC Core Offloads specifications". Willem will go over some critical offloads, from established to novel ongoing work, such as pacing and inline crypto and show how they can fail in practice. And last but not least provide an overview of some of the testcases which have already been contributed to the kernel tree including tests for RSS, HW-GRO, TSO and others. cheers, jamal PS: 6 more days left for early-bird registration. visit netdevconf.info/0x17/registration

1 0

0x17: talk, Improving multi-phy and multi-port interfaces
by Jamal Hadi Salim 01 Oct '23

01 Oct '23

How do we deal with a single MAC connected to multiple PHYs - whether chained or in parallel - with multiple front-facing ports? What about when multiple front facing ports utilizing a single PHY or, fun, multiple PHYs? Maxime Chevallier we have some support for these scenarios today where we hide the PHY behind a netdev. The consequences are there is no way to config an individual PHY when multiple PHYs are present on a link - think SFP transceivers for example. Selecting which front-facing port to use is also limited. In this talk, Maxime will describe ongoing work to support these complex topologies, the challenges faced and expected improvements. cheers, jamal PS: 6 more days left for early-bird registration. visit netdevconf.info/0x17/registration

1 0

0x17: Talk, Is scaling eBPF easy yet? A small step to one server, but giant leap to distributed network.
by Jamal Hadi Salim 30 Sep '23

30 Sep '23

After deploying eBPF for over a year in a distributed service provider production environment Ivan Koveshnikov has come to the conclusion that there are a lot more challenges than simply slicing and dicing packets....What happens on "day 2" after the celebrations ends? In this talk Ivan will discuss important topics: development process, application lifetime management, configuration management and delivery, monitoring and observability, and scaling in the service providers' network. Using eBPF in such an environment adds extra spicing to the process challenges. Come and learn from Ivan's experiences! cheers, jamal Reminder: 6 more days left for early-bird registration. visit netdevconf.info/0x17/registration

1 0

0x17: Power-Aware Network Performance BoF
by Jamal Hadi Salim 30 Sep '23

30 Sep '23

Traditional host Network performance measurements are based on analyzing the correlation between the two classical metrics of throughput and latency against cpu utilization. This approach leaves out an important metric: Power utilization. The huge influx of AI infrastructure - which ends up consuming network resources - has brought much needed attention to power consumption as a variable in network infrastructure. If you consider that the operational cost of power is going up (significantly in some parts of the world with the ongoing crisis) we cannot ignore networking infrastructure contributions to not just the cost factor but also the environmental harm brought forth with high power use. Nabil Bitar, Jamal Hadi Salim and Pedro Tammela feel that Linux, which dominates data center deployments, deserves special attention. There is not much literature or shared experience in this space so they hope to inspire a discussion by sharing their experiences with the community: How would one go about measuring power utilization for network workloads? How do we correlate metrics such as perf, throughput, etc to the power utilized? How would one go about saving power while still achieving an application's stated end goals? If you would like to share your experiences or solutions on this important topic please reach out to me. The agenda is still open. cheers, jamal

2 2

0x17: BoF, Compiler-networking workshop
by Jamal Hadi Salim 28 Sep '23

28 Sep '23

If you thought, as a Linux networking person, that you only needed to sift through the truth^Whype on Rust, CXL, P4, ML/AI then you are mistaken. You also need to learn about compilers!.. Ok, just kidding. But seriously - compilers are the future! In the near future a lot of the networking infrastructure code will be compiler generated. In this exciting workshop, Felipe Alemeida, Tom Herbert, Bala Sambasivam, Neil Turton and Stephan Diestelhorst we will discuss how compilers are developing to accelerate network processing with new techniques, and how essential they are for the higher throughput and flexibility that datacenters need. They will discuss different abstractions for network problems that compilers can leverage to optimize networking and how different abstractions and languages transform to actual programs and instructions for optimal execution on next-generation network devices. Topics include: eBPF compilers, P4 compilers, MLIR, new intermediate representations, data flow analysis, multi-platform support, static analysis, and other advanced topics related to compilers and networking. If you would like to discuss something on this related topic then please reach out to Tom and/or Felipe to be considered for the agenda. cheers, jamal

1 0

0x17: TC workshop
by Jamal Hadi Salim 27 Sep '23

27 Sep '23

Jamal Hadi Salim will chair the classical TC workshop at 0x17. Unicast a request if you have a TC topic you feel is worthy of discussion. Current WAG agenda (subject to update): - The trials and tribulations of attempting to improve the CAKE bufferbloat wars - New TC features requests/improvements - Performance - Test integration progress cheers, jamal

6 6

0x17: BoF, CXL : An overview and applicability to high performance networking
by Jamal Hadi Salim 27 Sep '23

27 Sep '23

If you have not heard of the new 3 letter acronym, CXL(Compute eXpress Link), you will hear a lot more about it in the future. For the uninformed, CXL is an open standard for high-speed, high capacity CPU-to-device and CPU-to-memory connections. At 0x17, Shrijeet Mukherjee will lead a BOF on CXL and it's applicability to networking. Merging the IO and Compute expansion protocols has always been a desired attribute as it allows dis-aggregation of the memory capacity from the compute capacity, and specifically for networking it allows buffer and control state placement to be moved closer to IO and offload devices. If you would like to speak at this BoF on topics covering the state of the art of CXL and the platforms that support it or talk about innovative solutions that CXL enables please reach out to Shrijeet. cheers, jama

1 0

0x17: Rust for Linux Networking Tutorial
by Jamal Hadi Salim 26 Sep '23

26 Sep '23

So you've heard of Rust and you have heard, while walking around the grape vine, about Rust for Linux. You are a hardcore linux kernel hacker and you love your C. You scratch your head as you wonder why in the world would anyone need another language! But at the same time you cant stand all those annoying pesty syzkaller bug reports or CVEs on your code - they take away all the fun. Rust has a key property that makes it very interesting as the second language in the kernel: it guarantees no undefined behavior takes place (as long as unsafe code is sound). This includes no use-after-free mistakes, no double frees, no data races, etc. It also provides other important benefits, such as improved error handling, stricter typing, sum types, pattern matching, privacy, closures, generics, etc. In this tutorial two of the gurus in Rust for Linux, Wedson Almeida Filho and Miguel Ojeda will guide us through a practical example which will use an example of kernel networking code. The sample code is first written in C and then migrated to Rust. Wedson and Miguel will then do a step-by-step walk of the Rust incarnation of the code, explaining how the language works at a high-level and well as giving practical tips to get started with Rust for networking in the kernel. Our esteemed guides will show us how Rust prevents some of the mistakes that could happen in the C version, some of which could become vulnerabilities exploited by bad operators or that pesky syzkaller. There is no prerequisite Rust knowledge needed for this tutorial. cheers, jamal

1 0

0x17: Workshop, Artificial Intelligence and Machine Learning in Networking
by Jamal Hadi Salim 25 Sep '23

25 Sep '23

Ok, so you are a networking Linux person and you are trying to wade your way around all this ML and AI hype. ChatGTP is just not helping make you feel better. Sigh. All the relatives and friends are telling you how this is the future and worse you feel left out..... Well, fear no more. Our chairs Marta Plantykow and Roopa Prabhu have a plan to get you on good footing. The current agenda includes the following topics (more could be added later): 1) A tutorial by Marta Plantykow "Bridging networking and AI: Empowering Networking Engineers with Artificial Intelligence": The tutorial will be an overview of the fundamental concepts of AI/ML and their relevance to networking. Through relatable examples and approachable explanations, attendees will better understand how AI can enhance networking. While the discourse maintains a high-level perspective, it aims to demystify the notion that AI is overly complex and inaccessible. 2) Roopa Prabhu will discuss LLM's and generative AI in Network operations and Cyber-security 3) Milena Olech , Marta Plantykow and Maciek Machnikowski will talk about "Genetic Algorithm based PI controller tuning with stability analysis for Linux ptp4l optimization" which continues their work for tuning the Proportional-Integral (PI) controller configurable in the phc2sys application using Genetic Algorithm presented on Netdev 0x15[1]. More details on this workshop can be found at: https://netdevconf.info/0x17/sessions/workshop/artificial-intelligence-and-… cheers, jamal [1] https://netdevconf.info/0x15/session.html?Precision-Time-Protocol-optimizat…

1 0

2025

2024

2023

2022

2021

2020

2019

2018

people