DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC4BD20868
MIME-Version: 1.0
References: <cover.1543343124.git.lorenzo.bianconi@redhat.com>
 <8736rla4ow.fsf@purkki.adurom.net> <20181128104436.GA2298@localhost.localdomain>
 <87bm69v0ol.fsf@toke.dk> <20181128164306.0135ca83@redhat.com>
 <20181129103054.GA6365@localhost.localdomain> <87sgzkqaip.fsf@toke.dk>
In-Reply-To: <87sgzkqaip.fsf@toke.dk>
From:   =?UTF-8?Q?Micha=C5=82_Kazior?= <kazikcz@gmail.com>
Date:   Thu, 29 Nov 2018 14:41:51 +0100
Message-ID: <CABvG-CVFYNaytwaUj9YGVUp38DBP9CVYkoU6EKvbJBPNmtK0Ag@mail.gmail.com>
Subject: Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
To:     =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>
Cc:     lorenzo.bianconi@redhat.com, brouer@redhat.com,
        kvalo@codeaurora.org,
        linux-wireless <linux-wireless@vger.kernel.org>,
        Felix Fietkau <nbd@nbd.name>, borkmann@iogearbox.net,
        alexei.starovoitov@gmail.com,
        Linux Kernel Network Developers <netdev@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Thu, 29 Nov 2018 at 14:31, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.d=
k> 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=C5=82