[iovisor-dev] minutes: IO VIsor TSC/Dev Meeting
Hi All, Thanks for attending the meeting today. Here are my notes from the call. Cheers, Brenden === Status === Yonghong - Debugging incorrect user stack - fastpath vs slowpath register difference - should be updated in 4.9+ (LTS flavors) - user stack id - doesn't have full access, trying to improve - bpf perf event introspection Daniel cgroup bind and connect patches merged - 3 new hooks for container management - used by fb sockmap ingress support added raw tracepoint - use all tp arguments directly from bpf some prep patches for upcoming features - btf, few others clang compiled kernel issue with bpffs - c lang constant merging flag turned off Joe sock lookup progress - improvements to verifier for tracking reference scope - next rfc soon John Some patches merged, some just missed this window - next support for lookup by hash Adding Cilium support for sockmap soon Rearranging selftests/examples for sockmap Jakub adding support for offloading of a few features - inline map helpers - atomic add - some performance improvements Next window - perf ring output support Working on 32 bit register support in llvm Martin BTF support V2 - pretty print from kernel - includes pahole converter next: LLVM directly generate BTF with -g === Attendees === Dan Siemon Brenden Blanco Alex Reece Alexander Duyck Daniel Borkmann Jakub Kicinski Joe Stringer Mauricio Vasquez Yonghong Song Martin Quentin Monnet Tom George Wilson Andy Gospodarek Jiong Wang Saeed Francois Joel jcanseco ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
[iovisor-dev] Best userspace programming API for XDP features query to kernel?
Hi Suricata people, When Eric Leblond (and I helped) integrated XDP in Suricata, we ran into the issue, that at Suricata load/start time, we cannot determine if the chosen XDP config options, like xdp-cpu-redirect[1], is valid on this HW (e.g require driver XDP_REDIRECT support and bpf cpumap). We would have liked a way to report that suricata.yaml config was invalid for this hardware/setup. Now, it just loads, and packets gets silently dropped by XDP (well a WARN_ONCE and catchable via tracepoints). My question to suricata developers: (Q1) Do you already have code that query the kernel or drivers for features? At the IOvisor call (2 weeks ago), we discussed two options of exposing XDP features avail in a given driver. Option#1: Extend existing ethtool -k/-K "offload and other features" with some XDP features, that userspace can query. (Do you already query offloads, regarding Q1) Option#2: Invent a new 'ip link set xdp' netlink msg with a query option. (Q2) Do Suricata devs have any preference (or other options/ideas) for the way the kernel expose this info to userspace? [1] http://suricata.readthedocs.io/en/latest/capture-hardware/ebpf-xdp.html#the-xdp-cpu-redirect-case -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
