"'[…] Despite having attracted a fair amount of interest from the development community, sched_ext has run into considerable opposition and seems far from acceptance into the mainline. The posting by Tejun Heo of a new version of the sched_ext series at the beginning of May has restarted this long-running discussion[…]'" #kernel#LinuxKernel
The latest #LKML discussion about the #BPF extensible scheduler class (or "sched_ext") for the #Linux#kernel since yesterday is active again after a post from peterz:
"'That is, from where I am sitting I see $vendor mandate their $enterprise product needs their $BPF scheduler. At which point $vendor will have no incentive to ever contribute back.
[…]
[…] GPL forces people to contribute back […] And I see the whole BPF thing as a run-around on that. '" #LinuxKernel
"'[…] been working on and polishing a little tool called udev-hid-bpf [1]. This is the scaffolding required quickly and easily write, test and eventually fix your HID input devices (mouse, keyboard, etc.) via a BPF program instead of a full-blown custom kernel driver or a semi-full-blown #kernel patch.'"
"'"bpftop provides a dynamic real-time view of running eBPF programs. It displays the average execution runtime, events per second, and estimated total CPU % for each program. This tool minimizes overhead by enabling performance statistics only while it is active."'"
"'"I’ve decided to start a series of blog posts to cover some details about scx_rustland, my little #Linux scheduler written in #Rust that runs in user-space.
[…]
The connection with the #kernel happens thanks to #eBPF and sched-ext: together they allow to channel all the scheduling events to a user-space program, which then […]"'"
"[…] I learn how stuff works by building things with the aforementioned stuff. To get a proper grasp on #eBPF, I'll build a program that leverages eBPF to intercept SSL traffic in user-space, capturing data before it is encrypted (outgoing messages) and after it is decrypted (incoming messages). This'll let us read wire-encrypted SSL traffic on our local system without proxies, or having to meddle directly with the processes involved.[…]"
The "#eBPF for #Linux Admins" series from Ansil Hameed grew and right now contains seven parts.
It among others covers how to write a "eBPF program to block all packets via XDP"[1] and how to "block a TCP port of an interface instead of all packet"[2].
This article series based on his "journey to demystify eBPF" also covers some eBPF basics and things related to it: https://ansilh.com/tags/ebpf/
"[…] The lack of unbounded loops in [#eBPF] and some other freely expressible way of manipulating data mean that extra thought has to be given when looking and parsing application data. But with a thoughtful approach I don’t see why most protocols can’t be processed by eBPF, today we need to bind programs to TC (Traffic Control) but once XDP has egress support we can offload so much application processing […] #BPF
"'"[…] #eBPF programs are compiled down to eBPF bytecode and attached to hooks in the kernel via a syscall. This is tedious; so many libraries for eBPF allow you to write applications using and interacting with eBPF in C++, Rust, Go, Python, and even Lua.
But there are none for #Java, which is a pity. So… I decided to write bindings using the new Foreign Function API (Project Panama, preview in 21) and #bcc […]"'"
Cybercriminals started using #BPF as an attack vector to run code in the operating systems of popular cloud-computing platforms to target specific industries.
#Linux#kernel developer Mel Gorman on the #BPF extensible scheduler class" from Tejun and other Meta devs:
"""I view pluggable scheduler as something that would be a future maintenance nightmare […]
I generally worry that certain things may not have existed in the shipped scheduler if plugging was an option including EAS, throttling control, schedutil integration, big.Little, adapting to chiplets and picking preferred SMT siblings for turbo boost. […]"""
- it is not in #BPF, we cannot talk about it at netdev conf. […]```
/me wonders what this kind of argument should be called; "appeal to cool technology" maybe?
Source: "[RFC bpf-next 0/8] BPF 'force to MPTCP'"
<https://lore.kernel.org/mptcp/cover.1688616142.git.geliang.tang@suse.com/> #Linux #kernel #eBPF #LinuxKernel #MPTCP
I'm really surprised by this #bpf claim in Documentation/bpf/kfuncs.rst:
"Unlike with regular kernel symbols, this is expected behavior for BPF symbols, and out-of-tree BPF programs that use kfuncs should be considered relevant to discussions and decisions around modifying and removing those kfuncs. The BPF community will take an active role in participating in upstream discussions when necessary to ensure that the perspectives of such users are taken in"
I think this is a really cool in light of increasing interest in immutable distros for work and home, or even if you don’t know how to tune things yourself and want it to just work.
Introducing bpftune, an automatic configurator that monitors your workloads and sets the correct [#Linux] #kernel parameter values! […] using #BPF […] pluggable infrastructure that is open to contributions. […]#eBPF#LinuxKernel
Oracle introducing bpftune to tune your sysctl tunables automatically via bpf (blogs.oracle.com)
I think this is a really cool in light of increasing interest in immutable distros for work and home, or even if you don’t know how to tune things yourself and want it to just work.