DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B5B22206B6
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
To:     Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc:     Kalle Valo <kvalo@codeaurora.org>, 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: <20181128143533.GE2298@localhost.localdomain>
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>
Date:   Wed, 28 Nov 2018 15:43:18 +0100
Message-ID: <87zhtttg8p.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Lorenzo Bianconi <lorenzo.bianconi@redhat.com> writes:

>> Lorenzo Bianconi <lorenzo.bianconi@redhat.com> writes:
>> 
>> >> >> > This series is intended as a playground to start experimenting/developing
>> >> >> > with XDP/eBPF over WiFi and collect ideas/concerns about it.
>> >> >> > Introduce XDP support to mt76x2e/mt76x0e drivers. Currently supported
>> >> >> > actions are:
>> >> >> > - XDP_PASS
>> >> >> > - XDP_ABORTED
>> >> >> > - XDP_DROP
>> >> >> > Introduce ndo_bpf mac80211 callback in order to to load a bpf
>> >> >> > program into low level driver XDP rx hook.
>> >> >> > This series has been tested through a simple bpf program (available here:
>> >> >> > https://github.com/LorenzoBianconi/bpf-workspace/tree/master/mt76_xdp_stats)
>> >> >> > used to count frame types received by the device.
>> >> >> > Possible eBPF use cases could be:
>> >> >> > - implement new statistics through bpf maps
>> >> >> > - implement fast packet filtering (e.g in monitor mode)
>> >> >> > - ...
>> >> >
>> >> > Hi Kalle,
>> >> >
>> >> >> 
>> >> >> This is most likely a stupid question, but why do this in the driver and
>> >> >> not in mac80211 so that all drivers could benefit from it? I guess there
>> >> >> are reasons for that, I just can't figure that out.
>> >> 
>> >> XDP achieves its speedup by running the eBPF program inside the driver
>> >> NAPI loop, before the kernel even touches the data in any other capacity
>> >> (and in particular, before it allocates an SKB). Which kinda means the
>> >> hook needs to be in the driver... Could be a fallback in mac80211,
>> >> though; although we'd have to figure out how that interacts with Generic
>> >> XDP.
>> >> 
>> >> > 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!
>> >
>> > Hi Toke,
>> >
>> >> 
>> >> 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?
>> >> 
>> >
>> > You are right, my assumption here is the logic/complexity is moved to
>> > the bpf program that needs to take care of all possible issues that
>> > can be introduced. More or less it is the same if a bpf program mess
>> > up with TCP segments on a wired connection, isn't it?
>> 
>> No, I guess not; except here it potentially applies to all packets
>> (things like BAW tracking), and it is *in addition* to TCP.
>
> Yes, here it is a little bit harder, but I was meaning that the bpf program
> has to be very careful when dropping a packet :)

Yeah. What kind of filtering were you thinking you would use this for in
the short term?

-Toke