DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C89F20848
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> <20181128131141.GD2298@localhost.localdomain>
 <875zwhuvta.fsf@toke.dk> <20181128143533.GE2298@localhost.localdomain>
 <87zhtttg8p.fsf@toke.dk> <20181128153508.GG2298@localhost.localdomain>
 <87in0gu78s.fsf@toke.dk> <20181129125929.GB6365@localhost.localdomain>
 <CABvG-CVpYXpjE9vxsA90qzsGm3n48SBYv-dYWAB8vi9-dvhK4A@mail.gmail.com>
 <87k1kwq9bo.fsf@toke.dk> <bb855ffd6043743ef10058c9395d0c6b42a7832a.camel@sipsolutions.net>
 <87bm62jtbu.fsf@toke.dk> <4e2d8543c6e4e48d6b6a9f4fde5c811dd4d71243.camel@sipsolutions.net>
In-Reply-To: <4e2d8543c6e4e48d6b6a9f4fde5c811dd4d71243.camel@sipsolutions.net>
From:   Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Mon, 3 Dec 2018 21:00:54 +0100
Message-ID: <CAJ0CqmXnNNZUX1C0Zu0unof_5MxEVVtyO=k3vXGAVB04nMdm9A@mail.gmail.com>
Subject: Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>,
        kazikcz@gmail.com, Kalle Valo <kvalo@codeaurora.org>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        Felix Fietkau <nbd@nbd.name>,
        Jesper Dangaard Brouer <brouer@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

> On Mon, 2018-12-03 at 21:36 +0200, Toke Høiland-Jørgensen wrote:
> > Hi Johannes
> >
> > I think your email can be basically summed up to:
> >
> > > [ ... ] but really I think it's a can of worms.
> >
> > ...right? :)
>
> Heh, yeah :)
>
> > I sort of had a feeling it would be, but thank you for spelling out in
> > excruciating detail why that is so.
>
> :-)
>
> > Given this, I think I agree that it's not worth it for now, and we
> > should hold off on adding XDP support until we have 802.3/.11 conversion
> > offload working... Which I think is also where you ended up? :)
>
> That case is at least easy, yeah. And it seems kinda likely that we'll
> end up with that in all well-maintained drivers in the relatively near
> future anyway?

Hi all,

thanks for sharing your thoughts and concerns, as already stated the
main goal of this series
is get feedbacks and/or blocking points to start experimenting with
eBPF over 802.11 devices.
Reviewing the points indicated by Johannes, 802.11 protocol is too
complicated to be managed without skb
allocation. I agree that for the moment XDP/eBPF can be useful for
devices that supports hw offloading
(or FullMac devices?) since all the tricky aspects are already managed
in the firmware and we can take care of XDP stuff.
Probably in the near future we will respin this argument :)

>
> BTW, in a sense I still kind of want to add eBPF to the mac80211 ingress
> path, just not in the XDP sense. For example, I had a proposal a while
> ago to add a filter to the monitor mode RX path(s) in eBPF; I still
> think that's useful.
>
> I also think it may be useful to put eBPF programs into per-netdev
> ingress path, in order to e.g. collect statistics, rather than hard-
> coding all kinds of statistics into mac80211.
>
> All of these things I consider absolutely useful and helpful. I like
> eBPF and the flexibility it affords. I just really don't think we should
> call it XDP or let it do similar things to XDP like dropping or
> redirecting frames.
>

+1 :)

Regards,
Lorenzo

> johannes
>