Re: [iovisor-dev] [Oisf-devel] Best userspace programming API for XDP features query to kernel?
On Thu, 5 Apr 2018 09:47:37 +0200 Victor Julienwrote: > > Option#2: Invent a new 'ip link set xdp' netlink msg with a query option. > > Do you have an example of how this is queried? The code for querying should not be too difficult. It would likely be similar to how we currently "set"/attach an XDP program, via its BPF file-descriptor to an ifindex. Eric Leblond, choose to hide this in the kernel library "libbpf", see code: function bpf_set_link_xdp_fd() https://github.com/torvalds/linux/blob/master/tools/lib/bpf/bpf.c#L456-L575 Given Suricata already depend on libbpf for eBFP and XDP support, then it might make sense to add an API call to "get" XDP link info, e.g. bpf_get_link_xdp_features(int ifindex) ? -- 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
Re: [iovisor-dev] [Oisf-devel] Best userspace programming API for XDP features query to kernel?
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. > On Apr 4, 2018, at 5:28 AM, Jesper Dangaard Brouerwrote: > > 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 > ___ > Suricata IDS Devel mailing list: oisf-de...@openinfosecfoundation.org > Site: http://suricata-ids.org | Participate: > http://suricata-ids.org/participate/ > List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel > Redmine: https://redmine.openinfosecfoundation.org/ > ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] [Oisf-devel] Best userspace programming API for XDP features query to kernel?
> On 5 Apr 2018, at 09:47, Victor Julienwrote: > >> On 04-04-18 14:28, Jesper Dangaard 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[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) > > I think if it would use the ioctl ETHTOOL interface it'd be easiest for > us, as we already have code for this in place to check for offloading > settings. See [1]. > > >> Option#2: Invent a new 'ip link set xdp' netlink msg with a query option. > > Do you have an example of how this is queried? > > >> (Q2) Do Suricata devs have any preference (or other options/ideas) for >> the way the kernel expose this info to userspace? > > Right now I think extending the ethtool logic is best for us. > +1 I would prefer that approach too. > > [1] https://github.com/OISF/suricata/blob/master/src/util-ioctl.c#L326 > > -- > - > Victor Julien > http://www.inliniac.net/ > PGP: http://www.inliniac.net/victorjulien.asc > - > ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] [Oisf-devel] Best userspace programming API for XDP features query to kernel?
On 04-04-18 14:28, Jesper Dangaard 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[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) I think if it would use the ioctl ETHTOOL interface it'd be easiest for us, as we already have code for this in place to check for offloading settings. See [1]. > Option#2: Invent a new 'ip link set xdp' netlink msg with a query option. Do you have an example of how this is queried? > (Q2) Do Suricata devs have any preference (or other options/ideas) for > the way the kernel expose this info to userspace? Right now I think extending the ethtool logic is best for us. [1] https://github.com/OISF/suricata/blob/master/src/util-ioctl.c#L326 -- - Victor Julien http://www.inliniac.net/ PGP: http://www.inliniac.net/victorjulien.asc - ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev