Walmart Pushes Open-Source L3AF To Help Out eBPF Ecosystem

[phoronix]

Phoronix: Walmart Pushes Open-Source L3AF To Help Out eBPF Ecosystem

Retail shopping giant Walmart has found use out eBPF programs and today announced the open-source L3AF to help in the effort...

https://www.phoronix.com/scan.php?page=news_item&px=Walmart-L3AF-eBPF

[tildearrow]

This eBPF thing... Is it the end of kernel modules/DKMS yet?

Leaf? eBeePF? Honey?...

[Ironmask]

This eBPF thing... Is it the end of kernel modules/DKMS yet?

Leaf? eBeePF? Honey?...

eBPF is very limited (on purpose), it's not even turing complete. It's not meant to replace kernel modules, it's just meant to make certain tasks safer and easier to perform, like the fabled packet processing that it gets constantly mentioned with. Kernel modules will still always exist.

[tildearrow]

eBPF is very limited (on purpose), it's not even turing complete. It's not meant to replace kernel modules, it's just meant to make certain tasks safer and easier to perform, like the fabled packet processing that it gets constantly mentioned with. Kernel modules will still always exist.

Then how come CO-RE exists that allows compiling C pro- wait never mind it's another thing...

[xhustler]

Market place for eBPF modules - sounds good and interesting but my spidey-sense is tingling. Do we really want to commercialize something like eBPF?

[linuxgeex]

I find this extremely cool. And I echo the sentiment of tildearrow around using eBPF to replace some kernel module functionality, ie so vendors can produce drivers which are platform-agnostic. However this will not happen while the Linux kernel makes no promises about stable internal ABI, so the sentiment is only a sentiment lol.

As for how eBPF might be used in driver implementation today - think standard existing modules with some hooks to eBPF programs being used to manage hardware state so that a new device is configured/cajoled into a compliant operating mode, either at bringup or around certain operations.

[flower]

I find this extremely cool. And I echo the sentiment of tildearrow around using eBPF to replace some kernel module functionality, ie so vendors can produce drivers which are platform-agnostic. However this will not happen while the Linux kernel makes no promises about stable internal ABI, so the sentiment is only a sentiment lol.

As for how eBPF might be used in driver implementation today - think standard existing modules with some hooks to eBPF programs being used to manage hardware state so that a new device is configured/cajoled into a compliant operating mode, either at bringup or around certain operations.

they could make the eBPF API stable. Just like their userland api is stable

[yump]

"Stable" isn't exactly real. What you actually have is

1. Is it tested before release?
2. If the tests break, is anyone contractually obligated to fix it?
3. If the tests break, does anyone feel morally obligated to fix it?
4. Does the testing actually cover the behavior of the system you care about? (See also: Hyrum's law.)

Tracepoints are kind of stable kernel API.

A couple weeks ago, I hacked up a bpftrace script to measure CPU frequency histograms, weighted by wall time, unhalted time, and CPU cycles. Got everything working hunky-dory on my Haswell machine. Then I sftp'd it over to my brother's Skylake, and it turns out that the power:cpu_frequency tracepoint doesn't ever fire on recent CPUs with hardware p-state control.

The kernel API that script uses is "stable", but surprise surprise, the CPU API is not!

[linuxgeex]

they could make the eBPF API stable. Just like their userland api is stable

By definition the eBPF API has to be stable since it is a userspace-facing kernel API.

I think you mean the eBPF API on the kernel side. Your wish implies that eBPF interacts with stable interfaces within the kernel. However the linux kernel policy for internal interfaces is that everything is subject to change without notice. So your wish sadly is not going to come true, ever.