[PATCH] iw: dump 'rx bitrate' in link stats
We include it in 'station dump' but not 'link'.
Signed-off-by: Brian Norris
---
link.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/link.c b/link.c
index 0a323920ff2f..1ed7f631a121 100644
--- a/link.c
+++ b/link.c
@@ -121,6 +121,7 @@ static int print_link_sta(struct nl_msg *msg, void *arg)
[NL80211_STA_INFO_RX_PACKETS] = { .type = NLA_U32 },
[NL80211_STA_INFO_TX_PACKETS] = { .type = NLA_U32 },
[NL80211_STA_INFO_SIGNAL] = { .type = NLA_U8 },
+ [NL80211_STA_INFO_RX_BITRATE] = { .type = NLA_NESTED },
[NL80211_STA_INFO_TX_BITRATE] = { .type = NLA_NESTED },
[NL80211_STA_INFO_LLID] = { .type = NLA_U16 },
[NL80211_STA_INFO_PLID] = { .type = NLA_U16 },
@@ -160,6 +161,12 @@ static int print_link_sta(struct nl_msg *msg, void *arg)
printf("\tsignal: %d dBm\n",
(int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_SIGNAL]));
+ if (sinfo[NL80211_STA_INFO_RX_BITRATE]) {
+ char buf[100];
+
+ parse_bitrate(sinfo[NL80211_STA_INFO_RX_BITRATE], buf,
sizeof(buf));
+ printf("\trx bitrate: %s\n", buf);
+ }
if (sinfo[NL80211_STA_INFO_TX_BITRATE]) {
char buf[100];
--
2.20.0.rc0.387.gc7a69e6b6c-goog
Re: AP6335 with mainline kernel
Hi Arend, On Wed, Nov 28, 2018 at 6:13 PM Arend van Spriel wrote: > Nice. Regarding your question in the earlier email, bit 27 in > boardflags3 forces the device to always select external LPO signal. When > the bit is not set it will select either internal or external. I don't > know what the criteria for that selection are. Thanks for your explanation and for the excellent hint on the lack of 32kHz support in the device tree. Really appreciate it! To close this thread, here is the dts patch that allows Wifi to work om the imx7d-pico-pi board: http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/616048.html Thanks, Fabio Estevam
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi writes: > On Nov 28, Toke Høiland-Jørgensen wrote: >> Lorenzo Bianconi writes: >> >> >> Lorenzo Bianconi 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? >> > > 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. > 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
Issue with STBC capability and forcing radio to 1x1 mode.
Hello, I notice some weird things while debugging an issue on a 4.16+ kernel with ath10k radio. It seems that the 'iw phy info' does not remove the TX-STBC info when changing the antenna mask _until_ some vdev is brought up. This makes it difficult to properly create hostapd config files. [root@lf0313-63e7 lanforge]# iw phy wiphy1 info|grep STB TX STBC RX STBC 1-stream TX STBC [root@lf0313-63e7 lanforge]# ./local/sbin/iw phy wiphy1 set antenna 1 1 [root@lf0313-63e7 lanforge]# iw phy wiphy1 info|grep STB TX STBC RX STBC 1-stream TX STBC [root@lf0313-63e7 lanforge]# iw phy wiphy1 info|grep STB TX STBC RX STBC 1-stream TX STBC [root@lf0313-63e7 lanforge]# ifconfig wlan1 up [root@lf0313-63e7 lanforge]# iw phy wiphy1 info|grep STB RX STBC 1-stream Any idea on this? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
[PATCH] mac80211: fix reordering of buffered broadcast packets
If the buffered broadcast queue contains packets, letting new packets bypass that queue can lead to heavy reordering, since the driver is probably throttling transmission of buffered multicast packets after beacons. Keep buffering packets until the buffer has been cleared (and no client is in powersave mode). Cc: sta...@vger.kernel.org Signed-off-by: Felix Fietkau --- net/mac80211/tx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 582b3d49f891..cd35af38d81f 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -439,8 +439,8 @@ ieee80211_tx_h_multicast_ps_buf(struct ieee80211_tx_data *tx) if (ieee80211_hw_check(>local->hw, QUEUE_CONTROL)) info->hw_queue = tx->sdata->vif.cab_queue; - /* no stations in PS mode */ - if (!atomic_read(>num_sta_ps)) + /* no stations in PS mode and no buffered packets */ + if (!atomic_read(>num_sta_ps) && skb_queue_empty(>bc_buf)) return TX_CONTINUE; info->flags |= IEEE80211_TX_CTL_SEND_AFTER_DTIM; -- 2.17.0
Re: AP6335 with mainline kernel
On 11/28/2018 7:08 PM, Fabio Estevam wrote: Hi Arend, On Wed, Nov 28, 2018 at 2:23 PM Fabio Estevam wrote: I am not sure if I can access this signal via scope. Good news! I managed to make mx7d to generate the 32kHz clock and now Wifi works with the default nvram file value: boardflags3 0x08101188 Nice. Regarding your question in the earlier email, bit 27 in boardflags3 forces the device to always select external LPO signal. When the bit is not set it will select either internal or external. I don't know what the criteria for that selection are. Regards, Arend
Re: brcmfmac: regression using AP mode
Hi, > Stefan Wahren hat am 26. November 2018 um 19:14 > geschrieben: > > > Hi Arend, > > > Arend van Spriel hat am 26. November 2018 um > > 11:11 geschrieben: > > > > So no AP listed here. I suspect Rafał was focusing on "device_ap_sme=1 > > use_monitor=1" scenario. You can try adding AP entry with similar rx > > bits as P2P_GO above. > > thanks this make all driver errors like "setting AP mode failed -52" > disappear, but now hostapd 2.6 seems to stuck in a loop during establishing > the link: > i increased the debug level of brcmfmac to 0x5 and i'm getting this while booting: [5.288806] brcmfmac: F1 signature read @0x1800=0x15264345 [5.289167] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/6 [5.293319] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51 base 0x1800 wrap 0x1810 [5.29] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000 [5.293344] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9 base 0x18002000 wrap 0x18102000 [5.293353] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000 [5.293362] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000 [5.293371] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0 base 0x wrap 0x18107000 [5.293379] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0 base 0x wrap 0x [5.295574] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x198000 size=819200 (0xc8000) sr=0 (0x0) [5.295686] brcmfmac: brcmf_chip_setup ccrev=51, pmurev=27, pmucaps=0x39d05f1b [5.295698] brcmfmac: brcmf_get_module_param Enter, bus=0, chip=17221, rev=6 [5.295765] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver strength init needed for chip BCM4345/6 rev 6 pmurev 27 [5.296204] brcmfmac: brcmf_sdio_probe completed!! [5.296219] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [5.413840] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x00198000; size=600487 [5.442090] random: crng init done [5.442105] random: 7 urandom warning(s) missed due to ratelimiting [5.539438] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x0025f940; size=1728 [5.636378] brcmfmac: brcmf_sdio_firmware_callback enable F2: err=0 [5.636577] brcmfmac: brcmf_bus_change_state ignoring transition, bus not attached yet [5.636819] brcmfmac: brcmf_add_if allocate netdev interface [5.637199] brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x001FF350 [5.638014] brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x001FF350 [5.641788] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [5.665557] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04 [5.666203] brcmfmac: brcmf_c_preinit_dcmds CLM version = API: 12.2 Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2018-03-09 18:56:28 [5.673860] brcmfmac: brcmf_feat_firmware_capabilities [ ap sta wme 802.11d 802.11h rm cqa cac dualband ampdu ampdu_tx ampdu_rx amsdurx tdls radio_pwrsave btamp p2p proptxstatus mchan p2po anqpo vht-prop-rates dfrts txpwrcache stbc-tx stbc-rx-1ss epno pfnx wnm bsstrans mfp ] [5.673890] brcmfmac: brcmf_feat_firmware_capabilities enabling feature: MCHAN [5.673899] brcmfmac: brcmf_feat_firmware_capabilities enabling feature: P2P [5.674522] brcmfmac: brcmf_feat_iovar_int_get enabling feature: PNO [5.675854] brcmfmac: brcmf_feat_iovar_int_get enabling feature: TDLS [5.676955] brcmfmac: brcmf_feat_iovar_int_get enabling feature: MFP [5.678014] brcmfmac: brcmf_feat_iovar_int_get enabling feature: FWSUP [5.678066] brcmfmac: brcmf_fws_attach FWS queueing will be avoided [5.678920] brcmfmac: brcmf_cfg80211_attach Registering custom regulatory [5.681508] brcmfmac: brcmf_setup_wiphybands nmode=1, vhtmode=1, bw_cap=(1, 7) [5.684720] brcmfmac: brcmf_setup_wiphybands nchain=1 [5.721118] brcmfmac: check_vif_up device is not ready : status (0) [5.721190] brcmfmac: brcmf_net_attach wlan0: Broadcom Dongle Host Driver [5.844422] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0252 [ 10.845747] brcmfmac: check_vif_up device is not ready : status (0) [ 11.612740] brcmfmac: check_vif_up device is not ready : status (0) [ 11.613251] brcmfmac: check_vif_up device is not ready : status (0) [ 11.614724] brcmfmac: check_vif_up device is not ready : status (0) [ 11.616385] brcmfmac: check_vif_up device is not ready : status (0) [ 11.637118] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event [ 11.638643] brcmfmac: brcmf_config_dongle power save set to enabled [ 11.639137] brcmfmac: brcmf_dongle_roam Internal Roaming = On [ 11.640504] brcmfmac: brcmf_cfg80211_change_iface IF Type = Infra [ 11.642531] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not
Re: AP6335 with mainline kernel
Hi Arend, On Wed, Nov 28, 2018 at 2:23 PM Fabio Estevam wrote: > I am not sure if I can access this signal via scope. Good news! I managed to make mx7d to generate the 32kHz clock and now Wifi works with the default nvram file value: boardflags3 0x08101188 Thanks a lot for your help!
Re: AP6335 with mainline kernel
Hi Arend, On Wed, Nov 28, 2018 at 2:11 PM Arend Van Spriel wrote: > Does it mean there is a regression in 4.20 for this board? I haven't tested it with 4.20 yet. >> Only change I needed was the one suggested by Arend in the nvram file: >> changed boardflags3 entry.from 0x08101188 to 0x101188. > > > Yes. That is understood. However, an external LPO clock may be more reliable > than using the internal, which is consequence of changing boardflags3. Just to make sure I understand the change: boardflags3 0x08101188 --> Wifi uses an external clock boardflags3 0x101188 ---> Wifi uses an internal clock Current dts does not output the 32kHz from MX7D to the Wifi chip, so I guess the below is correct. > So can the signal be measured with a scope to confirm it provides 32kHz? I am not sure if I can access this signal via scope. Thanks
Re: AP6335 with mainline kernel
Hi Cameron, On Sat, Nov 17, 2018 at 5:10 PM Fabio Estevam wrote: > Could you please test the following patch against mainline that > implements this suggestion? > http://dark-code.bulix.org/4m18pb-507579 I finally managed to get Wifi working on the imx7d-pico-pi board using mainline 4.19.2 without any dts change. Only change I needed was the one suggested by Arend in the nvram file: changed boardflags3 entry.from 0x08101188 to 0x101188. With this change I get: # iwconfig wlan0 essid ACCESSPOINT # wpa_passphrase ACCESSPOINT > /etc/wpa.conf * # wpa_supplicant -Dwext -iwlan0 -c /etc/wpa.conf & # Successfully initialized wpa_supplicant [ 59.091981] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 59.310095] brcmfmac: brcmf_run_escan: error (-52) [ 59.314949] brcmfmac: brcmf_cfg80211_scan: scan error (-52) ioctl[SIOCSIWSCAN]: Invalid exchange wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 [ 60.327177] brcmfmac: brcmf_run_escan: error (-52) [ 60.332152] brcmfmac: brcmf_cfg80211_scan: scan error (-52) ioctl[SIOCSIWSCAN]: Invalid exchange wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 [ 61.344358] brcmfmac: brcmf_run_escan: error (-52) [ 61.349198] brcmfmac: brcmf_cfg80211_scan: scan error (-52) ioctl[SIOCSIWSCAN]: Invalid exchange wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 wlan0: Trying to associate with 94:2c:b3:31:dc:xx (SSID='ACCESSPOINT' freq=2462 MHz) wlan0: Associated with 94:2c:b3:31:dc:xx wlan0: [ 65.266683] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready WPA: Key negotiation completed with 94:2c:b3:31:dc:xx [PTK=CCMP GTK=TKIP] wlan0: CTRL-EVENT-CONNECTED - Connection to 94:2c:b3:31:dc:xx completed [id=0 id_str=] # udhcpc -i wlan0 udhcpc: started, v1.29.3 [ 73.015896] random: mktemp: uninitialized urandom read (6 bytes read) udhcpc: sending discover udhcpc: sending select for 192.168.0.14 udhcpc: lease of 192.168.0.14 obtained, lease time 3600 [ 74.354463] brcmfmac: brcmf_inetaddr_changed: fail to get arp ip table err:-52 deleting routers [ 74.390701] random: mktemp: uninitialized urandom read (6 bytes read) adding dns 201.82.0.66 adding dns 201.82.0.61 adding dns 201.6.4.116 # # ping google.com PING google.com (216.58.202.174): 56 data bytes 64 bytes from 216.58.202.174: seq=0 ttl=50 time=26.328 ms 64 bytes from 216.58.202.174: seq=1 ttl=50 time=22.751 ms 64 bytes from 216.58.202.174: seq=2 ttl=50 time=48.735 ms 64 bytes from 216.58.202.174: seq=3 ttl=50 time=58.955 ms If I change the dts as per my last patch the Wifi does not work. Regards, Fabio Estevam
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
On Nov 28, Toke Høiland-Jørgensen wrote: > Lorenzo Bianconi writes: > > >> Lorenzo Bianconi 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? > 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. Regards, Lorenzo > -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi writes: >> Lorenzo Bianconi 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
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
> Lorenzo Bianconi 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 :) > > >> 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? > > 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... > Correct. Regards, Lorenzo > -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi 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. >> 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? 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
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Michał Kazior writes: > On Wed, 28 Nov 2018 at 13:39, Toke Høiland-Jørgensen > 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
Re: [RFC 0/5] 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) > >> > - ... > > > > 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? > 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? Regards, Lorenzo > > Adding in Jesper; maybe he has some thoughts on this? > > -Toke
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
On Wed, 28 Nov 2018 at 13:39, Toke Høiland-Jørgensen 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). > 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). Michał
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi writes: >> Lorenzo Bianconi 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! 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
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
> Lorenzo Bianconi 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. > > -- > Kalle Valo I thought about that possibility (and I think it is definitely valuable) but I preferred to work as close as possible to the hw running the bpf program before skb allocation. My primary goal when I started thinking about eBPF over WiFi was to perform fast packet filtering. I think these two possibility are not mutually exclusive, we can fall-back to mac80211 if hw driver does not support 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. Regards, Lorenzo
Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers
Lorenzo Bianconi 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) > - ... 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. -- Kalle Valo
