Re: [iovisor-dev] [Oisf-devel] Best userspace programming API for XDP features query to kernel?

2018-04-05 Thread Jesper Dangaard Brouer via iovisor-dev
On Thu, 5 Apr 2018 09:47:37 +0200
Victor Julien  wrote:

> > 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?

2018-04-05 Thread Michał Purzyński via iovisor-dev
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 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)
> 
> 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?

2018-04-05 Thread Peter Manev via iovisor-dev

> On 5 Apr 2018, at 09:47, Victor Julien  wrote:
> 
>> 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?

2018-04-05 Thread Victor Julien via iovisor-dev
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