Introduction
Power over Ethernet (PoE) is a technology that combines power and data transmission over a single Ethernet cable. It simplifies the installation of networked devices like cameras, phones, and wireless access points by eliminating the need for separate power cables. PoE standards define how power is delivered alongside data, ensuring compatibility across devices. Originally denoted as “Power via MDI” (Media Dependent Interface) in the 802.3 IEEE standard, it later evolved into the recognized term “PoE” in the 2022 version of the standard. PoE equipment consists of two key components: Power Sourcing Equipment (PSE) and Powered Devices (PD).
Linux support, DENT initiative
Up until recently, the upstream Linux kernel had absolutely no support for Power over Ethernet technologies. Due to that, every hardware vendor providing PoE hardware was delivering its own vendor-specific and non-standard solution, often centered around not so great user-space libraries, with dubious integration with the rest of the Linux ecosystem and networking stack, like is unfortunately still done quite often by hardware vendors.
The DENT project, which exists under the umbrella of the Linux Foundation, aims at using the Linux Kernel, Switchdev, and other Linux based projects as the basis for building a new standardized network operating system without abstractions or overhead. Among other things supported by DENT is dentOS, a SwitchDev based NOS built on top of Open Network Linux, which includes PoE support, but based on yet another non-standard fully user-space driven solution in the name of poed, where even the HW-specific drivers are implemented in user-space.
So DENT set as a goal to implement a fully upstream solution in the Linux kernel to properly support Power over Ethernet, and contracted Bootlin to perform this development and upstreaming effort.
Continue reading “Power over Ethernet (PoE) support into the official Linux Kernel”
F is more and more used in the industry, eBPF kernel developers give considerable attention to eBPF performance: some standard use cases like system monitoring involve hundreds of eBPF programs attached to events triggered at high frequencies. It is then paramount to keep eBPF programs execution overhead as low as possible. This blog post aims to shed some light on an internal eBPF mechanism perfectly showcasing those efforts: the eBPF trampoline.
