Extending the ethtools mechanism seems like a clean solution here. It is, by design, a 50% reporting tool and the XDP feature set would be just yet another feature here.
toggle quoted messageShow quoted text
On Apr 4, 2018, at 5:28 AM, Jesper Dangaard Brouer <brouer@...> wrote:
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, 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?
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Suricata IDS Devel mailing list: oisf-devel@...
Site: http://suricata-ids.org | Participate: http://suricata-ids.org/participate/