netdev - Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

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: <CABvG-CVFYNaytwaUj9YGVUp38DBP9CVYkoU6EKvbJBPNmtK0Ag@mail.gmail.com>
Date:   Thu, 29 Nov 2018 14:41:51 +0100
From:   Michał Kazior <kazikcz@...il.com>
To:     Toke Høiland-Jørgensen <toke@...e.dk>
Cc:     lorenzo.bianconi@...hat.com, brouer@...hat.com,
        kvalo@...eaurora.org,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Felix Fietkau <nbd@....name>, borkmann@...earbox.net,
        alexei.starovoitov@...il.com,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

On Thu, 29 Nov 2018 at 14:31, Toke Høiland-Jørgensen <toke@...e.dk> wrote:
[...]
> >> Option#3 is to say, Wifi XDP is so different that we should create a
> >> new (enum) bpf_prog_type.  And then still see if we can leverage some
> >> of the same core-code (as long as it doesn't slowdown performance).
> >>
> >
> > Do you think that Option#3 will be more 'future-proof' respect to
> > Option#1?
>
> My feeling is that WiFi devices are not sufficiently different to
> warrant a whole new program type. We risk combinatorial explosion for
> all the stuff that is the same, but now need to be tested for two (or N)
> types...

I'm not sure if my understanding is correct, but XDP seems like it can
(and intends to be able to?) act as a general purpose packet
accelerator (REDIRECT action was mentioned so I'm inferring..). In
such case you'll need to be able to perform transformations on packets
too, e.g. strip/prepend vlan tags, gre headers and what have you. The
802.3 <-> 802.11 conversion could be treated on equal terms.


Michał