netdev - Re: [PATCH v3 net-next RFC] Generic XDP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0861d2c9-a5ec-f40e-b849-f6421938b357@cumulusnetworks.com>
Date:   Wed, 12 Apr 2017 13:54:20 -0600
From:   David Ahern <dsa@...ulusnetworks.com>
To:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Cc:     xdp-newbies@...r.kernel.org
Subject: Re: [PATCH v3 net-next RFC] Generic XDP

On 4/12/17 12:54 PM, David Miller wrote:
> 
> This provides a generic SKB based non-optimized XDP path which is used
> if either the driver lacks a specific XDP implementation, or the user
> requests it via a new IFLA_XDP_FLAGS value named XDP_FLAGS_SKB_MODE.
> 
> It is arguable that perhaps I should have required something like
> this as part of the initial XDP feature merge.
> 
> I believe this is critical for two reasons:
> 
> 1) Accessibility.  More people can play with XDP with less
>    dependencies.  Yes I know we have XDP support in virtio_net, but
>    that just creates another depedency for learning how to use this
>    facility.
> 
>    I wrote this to make life easier for the XDP newbies.
> 
> 2) As a model for what the expected semantics are.  If there is a pure
>    generic core implementation, it serves as a semantic example for
>    driver folks adding XDP support.
> 
> This is just a rough draft and is untested.


packet passed to xdp seems to be messed up. Using samples/bpf/xdp1*.c as
an example:

Current with virtio-net:
# xdp1 3
proto 0:          0 pkt/s
proto 6:          2 pkt/s
proto 17:       1610 pkt/s
proto 17:      22785 pkt/s

Using the skb-mode:

# xdp1 3 skb-mode
proto 0:          2 pkt/s
proto 0:      10880 pkt/s
proto 0:      29990 pkt/s
proto 0:      16972 pkt/s


If I change ipproto in samples/bpf/xdp1_kern.c:

        if (h_proto == htons(ETH_P_IP))
                ipproto = parse_ipv4(data, nh_off, data_end);
        else if (h_proto == htons(ETH_P_IPV6))
                ipproto = parse_ipv6(data, nh_off, data_end);
        else
                ipproto = 63;

I get:

# xdp1 3 skb-mode
proto 63:       6538 pkt/s
proto 63:      23679 pkt/s
proto 63:      29974 pkt/s
proto 63:      29599 pkt/s

which suggests h_proto is goofed up with skb-mode.