add XDP support to mt76x2e/mt76x0e drivers

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)
- ...

Quoted 8 lines · Lorenzo Bianconi

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

Quoted 8 lines

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)
- ...

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.

Signature · 1 line

Kalle Valo

Quoted 18 lines

Quoted 8 lines · Lorenzo Bianconi

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

Quoted 8 lines

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,

Quoted 4 lines

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.

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.

Quoted 3 lines

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 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?).

On Wed, 28 Nov 2018 at 13:39, Toke Høiland-Jørgensen <[email protected]> wrote:[...]

Quoted 5 lines

Quoted 3 lines

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).

Quoted 9 lines

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?

Quoted 6 lines

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).

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 3 lines

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 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?).

Adding in Jesper; maybe he has some thoughts on this?

-Toke

Quoted 31 lines

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 10 lines

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?

Quoted 7 lines

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?).

Right, maybe can we have some kind of 'wifi' bpf helpers?

Quoted 50 lines · Lorenzo Bianconi

Quoted 31 lines

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 10 lines

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?

Quoted 4 lines

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.

Quoted 9 lines

Quoted 8 lines

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?).

Quoted 1 line

Right, maybe can we have some kind of 'wifi' bpf helpers?

Yeah, I guess we would at least need helpers to update any internal state in mac80211 (such as BAW), or BPF programs wouldn't even be able to drop packets without messing things up...

-Toke

Quoted 57 lines

Quoted 54 lines · Lorenzo Bianconi

Quoted 31 lines

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 10 lines

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?

Quoted 2 lines

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 :)

Quoted 57 lines · Lorenzo Bianconi

Quoted 57 lines

Quoted 54 lines · Lorenzo Bianconi

Quoted 31 lines

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 10 lines

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?

Quoted 5 lines

Quoted 2 lines

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

Quoted 65 lines · Toke Høiland-Jørgensen

Quoted 62 lines · Lorenzo Bianconi

Quoted 52 lines

Quoted 50 lines · Lorenzo Bianconi

Quoted 31 lines

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 10 lines

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?

Quoted 7 lines

Quoted 4 lines

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 :)

Quoted 3 lines

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

When I started working on XDP for mt76 I was thinking about BSSID filtering but I was looking for a more general solution respect to add that feature in the driver. Moreover we could use bpf for fast packet filtering when you add an interface in monitor mode.

Nevertheless I guess there could be other use cases not limited to frame filtering. My primary goal with this series is to collect ideas/concerns on WiFi XDP/eBPF possible uses cases.

Quoted 66 lines · Lorenzo Bianconi

Quoted 65 lines · Toke Høiland-Jørgensen

Quoted 62 lines · Lorenzo Bianconi

Quoted 52 lines

Quoted 50 lines · Lorenzo Bianconi

Quoted 31 lines

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 10 lines

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?

Quoted 7 lines

Quoted 4 lines

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 :)

Quoted 8 lines

Quoted 3 lines

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

When I started working on XDP for mt76 I was thinking about BSSID filtering but I was looking for a more general solution respect to add that feature in the driver. Moreover we could use bpf for fast packet filtering when you add an interface in monitor mode.

Yup, both of these make sense.

Quoted 3 lines

Nevertheless I guess there could be other use cases not limited to frame filtering. My primary goal with this series is to collect ideas/concerns on WiFi XDP/eBPF possible uses cases.

Well, Michał's idea about offloading is cool if it is possible to get vendors to implement it.

Other than that, if we can solve the issues with differences between 802.11 and plain Ethernet frames, I see no reason why it wouldn't be possible to implement an XDP fast-path for WiFi-to-Ethernet forwarding, which might be useful in an access point, especially as WiFi speeds increase.

The other direction will probably be more difficult, at least if 802.11 frames need to be built in software. It *might* be possible with the XDP egress hook we are planning (with a suitable set of helpers, the eBPF program could build the 802.11 frames), but I'm not really sure if that is worth doing as I'm quite sure there are some hairy edge cases there...

-Toke

Quoted 77 lines

Quoted 66 lines · Lorenzo Bianconi

Quoted 65 lines · Toke Høiland-Jørgensen

Quoted 62 lines · Lorenzo Bianconi

Quoted 52 lines

Quoted 50 lines · Lorenzo Bianconi

Quoted 31 lines

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 8 lines

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 10 lines

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?

Quoted 7 lines

Quoted 4 lines

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 :)

Quoted 8 lines

Quoted 3 lines

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

When I started working on XDP for mt76 I was thinking about BSSID filtering but I was looking for a more general solution respect to add that feature in the driver. Moreover we could use bpf for fast packet filtering when you add an interface in monitor mode.

Quoted 9 lines

Yup, both of these make sense.

Quoted 3 lines

Nevertheless I guess there could be other use cases not limited to frame filtering. My primary goal with this series is to collect ideas/concerns on WiFi XDP/eBPF possible uses cases.

Well, Michał's idea about offloading is cool if it is possible to get vendors to implement it.

Yep, would be very cool :)

Quoted 6 lines

Other than that, if we can solve the issues with differences between 802.11 and plain Ethernet frames, I see no reason why it wouldn't be possible to implement an XDP fast-path for WiFi-to-Ethernet forwarding, which might be useful in an access point, especially as WiFi speeds increase.

Agree

Quoted 6 lines

The other direction will probably be more difficult, at least if 802.11 frames need to be built in software. It *might* be possible with the XDP egress hook we are planning (with a suitable set of helpers, the eBPF program could build the 802.11 frames), but I'm not really sure if that is worth doing as I'm quite sure there are some hairy edge cases there...

The possible issue with XDP_DROP action you are referring to here is A-MPDU reordering on rx side, right? If so I guess the issue will be fixed by tid_agg_rx->reorder_timer. Are you referring to other possible edge cases?

Quoted 6 lines

The other direction will probably be more difficult, at least if 802.11 frames need to be built in software. It *might* be possible with the XDP egress hook we are planning (with a suitable set of helpers, the eBPF program could build the 802.11 frames), but I'm not really sure if that is worth doing as I'm quite sure there are some hairy edge cases there...

The possible issue with XDP_DROP action you are referring to here is A-MPDU reordering on rx side, right? If so I guess the issue will be fixed by tid_agg_rx->reorder_timer. Are you referring to other possible edge cases?

On Thu, 29 Nov 2018 at 14:00, Lorenzo Bianconi
<[email protected]> wrote:
[...]

Quoted 10 lines

Quoted 6 lines

The other direction will probably be more difficult, at least if 802.11 frames need to be built in software. It *might* be possible with the XDP egress hook we are planning (with a suitable set of helpers, the eBPF program could build the 802.11 frames), but I'm not really sure if that is worth doing as I'm quite sure there are some hairy edge cases there...

The possible issue with XDP_DROP action you are referring to here is A-MPDU reordering on rx side, right? If so I guess the issue will be fixed by tid_agg_rx->reorder_timer. Are you referring to other possible edge cases?

What I'm thinking is reordering could be one of possible things to offload to an XDP program. It would require per-station data structure to keep track of the frame sequence numbers (among other things). Same could be said for crypto offloads (would require XDP programs to be able to use crypto apis I guess?).

Quoted 1 line

[A-MPDU reordering]

In principle, all of this could be done. But we need to think carefully about what things it really makes sense to offload to XDP. In the general case, we will end up re-implementing all of mac80211 in eBPF, which is obviously not ideal.

For crypto in particular, I wonder if there is much of a speedup to be had if the crypto is in software anyway. Wouldn't that dominate the processing time?

[ ... ] but really I think it's a can of worms.

Hi Johannes

I think your email can be basically summed up to:

Quoted 1 line

[ ... ] but really I think it's a can of worms.

...right? :)

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? :)

Quoted 7 lines · Toke Høiland-Jørgensen

Hi Johannes

I think your email can be basically summed up to:

Quoted 1 line

[ ... ] but really I think it's a can of worms.

...right? :)

Heh, yeah :)

Quoted 2 lines

I sort of had a feeling it would be, but thank you for spelling out in excruciating detail why that is so.

:-)

Quoted 4 lines

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?

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.

Quoted 7 lines

Hi Johannes

I think your email can be basically summed up to:

Quoted 1 line

[ ... ] but really I think it's a can of worms.

...right? :)

Heh, yeah :)

Quoted 2 lines

I sort of had a feeling it would be, but thank you for spelling out in excruciating detail why that is so.

:-)

Quoted 3 lines

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?

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.

johannes

Quoted 19 lines · Lorenzo Bianconi

Quoted 18 lines

Quoted 8 lines · Lorenzo Bianconi

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

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 3 lines

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 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?).

Adding in Jesper; maybe he has some thoughts on this?

Quoted 58 lines · On Wed, 28 Nov 2018 13:36:26 +0100 Toke Høiland-Jørgensen <[email protected]> wrote:

Quoted 19 lines · Lorenzo Bianconi

Quoted 18 lines

Quoted 8 lines · Lorenzo Bianconi

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

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 3 lines

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 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?).

Quoted 1 line

Adding in Jesper; maybe he has some thoughts on this?

Today XDP assumes the frame is an Ethernet frame. With WiFi I guess this assumption change, right?

I worry a bit about this, as XDP is all about performance, and I don't
want to add performance regressions, by requiring all XDP programs or core-code to having to check-frame-type before proceeding. That said, I do think it is doable, without adding performance regressions.

Option #1 is to move the check-frame-type to setup time. By either having frame-type be part of eBPF prog, or supply frame-type as option XDP attach call. And then reject attaching XDP prog to a device, where the expected frame-type does not match.

Option#2, leave it up to eBPF-programmer if they want to add runtime checks. By extending xdp_rxq_info with frame-type (default to Ethernet), which allow the eBPF-programmer choose to write a generic XDP program that both work on Ethernet and WiFi, or skip-check as they know this will e.g. only run on Wifi. (Note xdp_rxq_info is static read-only info per RX-queue, will all Wifi frames have same frame-type?.

Also consider what happens in case of XDP_REDIRECT, from a Wifi NIC to an Ethernet NIC. It would of-cause be cool to get this working cross, Wifi-Ethernet.

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).

Signature · 4 lines

Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Quoted 61 lines

Quoted 58 lines · On Wed, 28 Nov 2018 13:36:26 +0100 Toke Høiland-Jørgensen…

Quoted 19 lines · Lorenzo Bianconi

Quoted 18 lines

Quoted 8 lines · Lorenzo Bianconi

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

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 3 lines

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 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?).

Quoted 1 line

Quoted 1 line

Adding in Jesper; maybe he has some thoughts on this?

Hi Jesper,

Quoted 3 lines

Today XDP assumes the frame is an Ethernet frame. With WiFi I guess this assumption change, right?

yes correct, SoftMAC devices report 802.11 frames to the stack

Quoted 10 lines

I worry a bit about this, as XDP is all about performance, and I don't
want to add performance regressions, by requiring all XDP programs or core-code to having to check-frame-type before proceeding. That said, I do think it is doable, without adding performance regressions.

Option #1 is to move the check-frame-type to setup time. By either having frame-type be part of eBPF prog, or supply frame-type as option XDP attach call. And then reject attaching XDP prog to a device, where the expected frame-type does not match.

I guess it will be enough to avoid loading a 'non-WiFi' bpf program on a 802.11 netdevice (and vice versa). We could add a flag (or something similar) in XDP_SETUP_PROG section of netdev_bpf data structure and use ieee80211_ptr netdevice pointer in order to guarantee that the bpf program will work on the expected 'frame-type'

Quoted 8 lines

Option#2, leave it up to eBPF-programmer if they want to add runtime checks. By extending xdp_rxq_info with frame-type (default to Ethernet), which allow the eBPF-programmer choose to write a generic XDP program that both work on Ethernet and WiFi, or skip-check as they know this will e.g. only run on Wifi. (Note xdp_rxq_info is static read-only info per RX-queue, will all Wifi frames have same frame-type?.

802.11 standards define three frame subtype (data, management and control). Subtypes could be detected parsing 802.11 header

Quoted 1 line

Quoted 4 lines

Also consider what happens in case of XDP_REDIRECT, from a Wifi NIC to an Ethernet NIC. It would of-cause be cool to get this working cross, Wifi-Ethernet.

Very cool :) On tx side the driver will accept standard ethernet frames in ndo_xdp_xmit pointer

Quoted 4 lines

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?

Quoted 5 lines

Quoted 4 lines

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).

Quoted 2 lines

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...

On Thu, 29 Nov 2018 at 14:31, Toke Høiland-Jørgensen <[email protected]> wrote:
[...]

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

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).

Quoted 7 lines

Quoted 2 lines

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.

Quoted 82 lines · Lorenzo Bianconi

Quoted 61 lines

Quoted 58 lines · On Wed, 28 Nov 2018 13:36:26 +0100 Toke Høiland-Jørgensen <[email protected]> wrote:

Quoted 19 lines · Lorenzo Bianconi

Quoted 18 lines

Quoted 8 lines · Lorenzo Bianconi

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

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 3 lines

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 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?).

Quoted 1 line

Quoted 1 line

Adding in Jesper; maybe he has some thoughts on this?

Hi Jesper,

Quoted 3 lines

Today XDP assumes the frame is an Ethernet frame. With WiFi I guess this assumption change, right?

yes correct, SoftMAC devices report 802.11 frames to the stack

Quoted 10 lines

I worry a bit about this, as XDP is all about performance, and I don't
want to add performance regressions, by requiring all XDP programs or core-code to having to check-frame-type before proceeding. That said, I do think it is doable, without adding performance regressions.

Option #1 is to move the check-frame-type to setup time. By either having frame-type be part of eBPF prog, or supply frame-type as option XDP attach call. And then reject attaching XDP prog to a device, where the expected frame-type does not match.

Quoted 5 lines

I guess it will be enough to avoid loading a 'non-WiFi' bpf program on a 802.11 netdevice (and vice versa). We could add a flag (or something similar) in XDP_SETUP_PROG section of netdev_bpf data structure and use ieee80211_ptr netdevice pointer in order to guarantee that the bpf program will work on the expected 'frame-type'

Yeah, a flag would be good; we've been discussing that for other XDP use cases; it's not a done deal yet, but I think it would be useful.

Quoted 18 lines

Quoted 8 lines

Option#2, leave it up to eBPF-programmer if they want to add runtime checks. By extending xdp_rxq_info with frame-type (default to Ethernet), which allow the eBPF-programmer choose to write a generic XDP program that both work on Ethernet and WiFi, or skip-check as they know this will e.g. only run on Wifi. (Note xdp_rxq_info is static read-only info per RX-queue, will all Wifi frames have same frame-type?.

802.11 standards define three frame subtype (data, management and control). Subtypes could be detected parsing 802.11 header

Quoted 5 lines

Also consider what happens in case of XDP_REDIRECT, from a Wifi NIC to an Ethernet NIC. It would of-cause be cool to get this working cross, Wifi-Ethernet.

Quoted 2 lines

Very cool :) On tx side the driver will accept standard ethernet frames in ndo_xdp_xmit pointer

How do you envision that will work with drivers that build software 802.11 frames? The TX hook would have to be in mac80211 somewhere, wouldn't it?

Quoted 6 lines

Quoted 5 lines

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).

Quoted 2 lines

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...

-Toke

Quoted 90 lines

Quoted 87 lines · Lorenzo Bianconi

Quoted 61 lines

Quoted 58 lines · On Wed, 28 Nov 2018 13:36:26 +0100 Toke Høiland-Jørgensen…

Quoted 19 lines · Lorenzo Bianconi

Quoted 18 lines

Quoted 8 lines · Lorenzo Bianconi

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

Quoted 8 lines

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)
- ...

Quoted 6 lines

Hi Kalle,

Quoted 4 lines

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.

Quoted 3 lines

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 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?).

Quoted 1 line

Quoted 1 line

Adding in Jesper; maybe he has some thoughts on this?

Hi Jesper,

Quoted 3 lines

Today XDP assumes the frame is an Ethernet frame. With WiFi I guess this assumption change, right?

yes correct, SoftMAC devices report 802.11 frames to the stack

Quoted 10 lines

I worry a bit about this, as XDP is all about performance, and I don't
want to add performance regressions, by requiring all XDP programs or core-code to having to check-frame-type before proceeding. That said, I do think it is doable, without adding performance regressions.

Option #1 is to move the check-frame-type to setup time. By either having frame-type be part of eBPF prog, or supply frame-type as option XDP attach call. And then reject attaching XDP prog to a device, where the expected frame-type does not match.

I guess it will be enough to avoid loading a 'non-WiFi' bpf program on a 802.11 netdevice (and vice versa). We could add a flag (or something similar) in XDP_SETUP_PROG section of netdev_bpf data structure and use ieee80211_ptr netdevice pointer in order to guarantee that the bpf program will work on the expected 'frame-type'

Quoted 2 lines

Yeah, a flag would be good; we've been discussing that for other XDP use cases; it's not a done deal yet, but I think it would be useful.

Do you think something wifi specific is ok (e.g bool wifi) or do you prefer something more general (e.g u32 frame_type)?

Quoted 17 lines

Quoted 17 lines

Quoted 7 lines

Option#2, leave it up to eBPF-programmer if they want to add runtime checks. By extending xdp_rxq_info with frame-type (default to Ethernet), which allow the eBPF-programmer choose to write a generic XDP program that both work on Ethernet and WiFi, or skip-check as they know this will e.g. only run on Wifi. (Note xdp_rxq_info is static read-only info per RX-queue, will all Wifi frames have same frame-type?.

802.11 standards define three frame subtype (data, management and control). Subtypes could be detected parsing 802.11 header

Quoted 5 lines

Also consider what happens in case of XDP_REDIRECT, from a Wifi NIC to an Ethernet NIC. It would of-cause be cool to get this working cross, Wifi-Ethernet.

Quoted 6 lines

Quoted 2 lines

Very cool :) On tx side the driver will accept standard ethernet frames in ndo_xdp_xmit pointer

How do you envision that will work with drivers that build software 802.11 frames? The TX hook would have to be in mac80211 somewhere, wouldn't it?

In order to perform 802.3 --> 802.11 xdp forwarding my current idea is is to have ndo_xdp_xmit pointer in mac80211 that will forward the frame to the low-level driver (more or less what I did in the RFC series to upload the bpf program to mt76). We will probably need to pass some info to the driver from mac80211 (e.g sequence number or hw key idx to use)

Quoted 5 lines · Lorenzo Bianconi

Quoted 5 lines

Quoted 3 lines · Lorenzo Bianconi

Quoted 3 lines

On Wed, 28 Nov 2018 13:36:26 +0100
Toke Høiland-Jørgensen <[email protected]> wrote:

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

I guess it will be enough to avoid loading a 'non-WiFi' bpf program on a 802.11 netdevice (and vice versa). We could add a flag (or something similar) in XDP_SETUP_PROG section of netdev_bpf data structure and use ieee80211_ptr netdevice pointer in order to guarantee that the bpf program will work on the expected 'frame-type'

Quoted 5 lines

Quoted 2 lines

Yeah, a flag would be good; we've been discussing that for other XDP use cases; it's not a done deal yet, but I think it would be useful.

Do you think something wifi specific is ok (e.g bool wifi) or do you prefer something more general (e.g u32 frame_type)?

My thought was a feature flag where the program can set a flag which means "I expect 802.11 frames", and the driver can set a flag saying "I emit 802.11 frames", and if those two flags don't match, the verifier can refuse to load the program. This would not be fool-proof (an XDP program can still corrupt things if written incorrectly), but it would at least protect against the most obvious mistakes.

Quoted 25 lines

Quoted 18 lines

Quoted 18 lines

Quoted 8 lines

Option#2, leave it up to eBPF-programmer if they want to add runtime checks. By extending xdp_rxq_info with frame-type (default to Ethernet), which allow the eBPF-programmer choose to write a generic XDP program that both work on Ethernet and WiFi, or skip-check as they know this will e.g. only run on Wifi. (Note xdp_rxq_info is static read-only info per RX-queue, will all Wifi frames have same frame-type?.

802.11 standards define three frame subtype (data, management and control). Subtypes could be detected parsing 802.11 header

Quoted 5 lines

Also consider what happens in case of XDP_REDIRECT, from a Wifi NIC to an Ethernet NIC. It would of-cause be cool to get this working cross, Wifi-Ethernet.

Quoted 6 lines

Quoted 2 lines

Very cool :) On tx side the driver will accept standard ethernet frames in ndo_xdp_xmit pointer

How do you envision that will work with drivers that build software 802.11 frames? The TX hook would have to be in mac80211 somewhere, wouldn't it?

Quoted 6 lines

In order to perform 802.3 --> 802.11 xdp forwarding my current idea is is to have ndo_xdp_xmit pointer in mac80211 that will forward the frame to the low-level driver (more or less what I did in the RFC series to upload the bpf program to mt76). We will probably need to pass some info to the driver from mac80211 (e.g sequence number or hw key idx to use)

So this means that the driver will need to do the 802.11 encapsulation? I guess we could have a fallback implementation in mac80211; but there is possibly quite a bit of refactoring needed to make the existing code work without an skb. Also, we need to think about queueing; I'm not sure it's a good idea to have redirected frames bypass the TXQs...

-Toke

Quoted 7 lines

Quoted 5 lines · Lorenzo Bianconi

Quoted 5 lines

Quoted 3 lines · Lorenzo Bianconi

Quoted 3 lines

On Wed, 28 Nov 2018 13:36:26 +0100
Toke Høiland-Jørgensen <[email protected]> wrote:

[...]

Quoted 13 lines

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

I guess it will be enough to avoid loading a 'non-WiFi' bpf program on a 802.11 netdevice (and vice versa). We could add a flag (or something similar) in XDP_SETUP_PROG section of netdev_bpf data structure and use ieee80211_ptr netdevice pointer in order to guarantee that the bpf program will work on the expected 'frame-type'

Quoted 5 lines

Quoted 2 lines

Yeah, a flag would be good; we've been discussing that for other XDP use cases; it's not a done deal yet, but I think it would be useful.

Do you think something wifi specific is ok (e.g bool wifi) or do you prefer something more general (e.g u32 frame_type)?

Quoted 6 lines

My thought was a feature flag where the program can set a flag which means "I expect 802.11 frames", and the driver can set a flag saying "I emit 802.11 frames", and if those two flags don't match, the verifier can refuse to load the program. This would not be fool-proof (an XDP program can still corrupt things if written incorrectly), but it would at least protect against the most obvious mistakes.

I guess we can use iee80211_ptr in dev_xdp_install to double check if it is allowed to upload a 802.11 (or 802.3) bpf program