DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 221CF20832
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
To:     =?utf-8?Q?Micha=C5=82?= Kazior <kazikcz@gmail.com>
Cc:     lorenzo.bianconi@redhat.com, kvalo@codeaurora.org,
        linux-wireless <linux-wireless@vger.kernel.org>, nbd@nbd.name,
        brouer@redhat.com
Subject: Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
In-Reply-To: <CABvG-CWkb80iVR=Q-q9a-n0x8Yy9NJAYjnTsOhfErpiOz2SDCw@mail.gmail.com>
References: <cover.1543343124.git.lorenzo.bianconi@redhat.com> <8736rla4ow.fsf@purkki.adurom.net> <20181128104436.GA2298@localhost.localdomain> <87bm69v0ol.fsf@toke.dk> <CABvG-CWkb80iVR=Q-q9a-n0x8Yy9NJAYjnTsOhfErpiOz2SDCw@mail.gmail.com>
Date:   Wed, 28 Nov 2018 15:19:21 +0100
Message-ID: <878t1duvx2.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Micha=C5=82 Kazior <kazikcz@gmail.com> writes:

> On Wed, 28 Nov 2018 at 13:39, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke=
.dk> wrote:[...]
>> > This is an early stage implementation, at this point I would collect
>> > other people opinions/concerns about using bpf/xdp directly on 802.11
>> > frames.
>>
>> Thanks for looking into this!
>
> I'm really hyped up with this especially when I think this could be
> maybe offloaded to wlan cpu's for e.g. deep powersaving (allow host
> system to suspend) without relying on blackbox logic you get today, or
> 802.11 -> 802.3 conversion (to offload host cpu).

Yeah, good point!

>> I have two concerns with running XDP on 802.11 frames:
>>
>> 1. It makes it more difficult to add other XDP actions (such as
>>    REDIRECT), as the XDP program would then have to make sure that the
>>    outer packet headers are removed before, say, redirecting the packet
>>    out of an ethernet interface. Also, if we do add redirect, we would
>>    be bypassing mac80211 entirely; to what extent would that mess up
>>    internal state?
>>
>> 2. UI consistency; suddenly, the user needs to know which kind of
>>    frames to expect, and XDP program reuse becomes more difficult. This
>>    may be unavoidable given the nature of XDP, but some thought needs to
>>    go into this. Especially since we wouldn't necessarily be consistent
>>    between WiFi drivers (there are fullmac devices that remove 802.11
>>    headers before sending up the frame, right?).
>
> Yep - you can expect 802.3 frames or amsdu subframes (DA+SA+length)
> too. In some cases you could also expect internal events (broadcom if
> I understand their fullmac arch).

Oh boy. I figured it was going to be a can of worms; didn't realise it
was quite that big :/

-Toke