Re: please update -head if you're running it - testing changes to NULL frames and sequence number offload
- Reply: Nuno Teixeira : "Re: please update -head if you're running it - testing changes to NULL frames and sequence number offload"
- In reply to: Nuno Teixeira : "Re: please update -head if you're running it - testing changes to NULL frames and sequence number offload"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 20 Sep 2025 21:14:14 UTC
Just cd src ; make buildkernel ; it will do an incremental build. then make reinstallkernel -adrian On Sat, 20 Sept 2025 at 13:42, Nuno Teixeira <eduardo@freebsd.org> wrote: > Ok, after reverting 5bf3c55 how do I quick compile it to avoid compile > entire kernel? > > Adrian Chadd <adrian@freebsd.org> escreveu (sábado, 20/09/2025 à(s) > 20:13): > >> >> >> On Sat, 20 Sept 2025 at 12:04, Nuno Teixeira <eduardo@freebsd.org> wrote: >> >>> Hello Adrian! >>> >>> I'm using iwx driver on my AX201 for some months and I saw it as stable >>> on my laptop. >>> (switching to iwlwifi, I saw that connection rate becomes degradated >>> after some hours, and some crashes too) >>> >>> I'm using main 20250920-e043af9ca596 . Today I upgraded to >>> 20250920-31ec8b6407fd and iperf3 tests to my router failed: >>> >>> - after failed iperf3, I need to restart servive netif to get internet >>> back. >>> - nothing in messages, dmesg, no crash >>> >> >> Hm. Yeah I saw some oddness like this, even before my work. >> >> Can you try reverting the iwx diffs until it works? Not the net80211 >> ones; as they're only enabled if you enable the iwx ones. >> >> here's the list to try reverting one at a time. They're one or two line >> diffs, you can totally do it locally without checking out a new tree, and >> reload the iwx module. :-) >> >> >> commit 5bf3c5586b5e8256af0c1a6916fb5fdc6c70b3c9 >> Author: Adrian Chadd <adrian@FreeBSD.org> >> Date: Wed Jun 4 20:50:33 2025 -0700 >> iwx: enable seqno offload >> >> Author: Adrian Chadd <adrian@FreeBSD.org> >> Date: Fri Aug 29 22:10:22 2025 -0700 >> >> [iwx] tell net80211 not to originate NULL data frames >> >> Lemme know what you see! >> >> Thanks! >> >> >> >> -adrian >> >> >> >> >> >>> iperf3 -c 192.168.1.1 >>> Connecting to host 192.168.1.1, port 5201 >>> [ 5] local 192.168.1.188 port 41996 connected to 192.168.1.1 port 5201 >>> [ ID] Interval Transfer Bitrate Retr Cwnd >>> [ 5] 0.00-1.06 sec 3.75 MBytes 29.6 Mbits/sec 110 214 KBytes >>> [ 5] 1.06-2.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >>> [ 5] 2.06-3.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >>> [ 5] 3.06-4.03 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >>> [ 5] 4.03-5.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >>> [ 5] 5.06-6.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >>> [ 5] 6.06-7.02 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >>> [ 5] 7.02-8.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >>> [ 5] 8.06-9.02 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >>> >>> - rolled back to latest BE: >>> >>> iperf3 -c 192.168.1.1 >>> Connecting to host 192.168.1.1, port 5201 >>> [ 5] local 192.168.1.188 port 49619 connected to 192.168.1.1 port 5201 >>> [ ID] Interval Transfer Bitrate Retr Cwnd >>> [ 5] 0.00-1.06 sec 2.88 MBytes 22.7 Mbits/sec 274 1.41 KBytes >>> [ 5] 1.06-2.00 sec 25.1 MBytes 224 Mbits/sec 79 280 KBytes >>> [ 5] 2.00-3.03 sec 31.6 MBytes 259 Mbits/sec 23 249 KBytes >>> [ 5] 3.03-4.06 sec 36.2 MBytes 295 Mbits/sec 2 263 KBytes >>> [ 5] 4.06-5.04 sec 35.2 MBytes 301 Mbits/sec 6 266 KBytes >>> [ 5] 5.04-6.03 sec 30.5 MBytes 259 Mbits/sec 3 236 KBytes >>> [ 5] 6.03-7.06 sec 31.6 MBytes 257 Mbits/sec 14 214 KBytes >>> [ 5] 7.06-8.06 sec 30.8 MBytes 259 Mbits/sec 0 368 KBytes >>> [ 5] 8.06-9.05 sec 30.6 MBytes 259 Mbits/sec 4 339 KBytes >>> [ 5] 9.05-10.01 sec 29.8 MBytes 260 Mbits/sec 2 330 KBytes >>> - - - - - - - - - - - - - - - - - - - - - - - - - >>> [ ID] Interval Transfer Bitrate Retr >>> [ 5] 0.00-10.01 sec 284 MBytes 238 Mbits/sec 407 >>> sender >>> [ 5] 0.00-10.02 sec 284 MBytes 237 Mbits/sec >>> receiver >>> >>> Thanks, >>> >>> Adrian Chadd <adrian@freebsd.org> escreveu (sábado, 20/09/2025 à(s) >>> 01:55): >>> >>>> hi! >>>> >>>> I've been sitting on this for a while and noodling on the devices I >>>> have here. >>>> If you're using -HEAD, please update and let me know if wifi is OK or >>>> not OK after today's commits. >>>> >>>> >>>> First up is enabling sequence number offloading in almost everything. I >>>> think the only thing left to do is the linuxkpi layer and then >>>> thoroughly test the heck out of it. The TL;DR is that now the sequence >>>> number assignment is done by a call from the driver - at the same time it's >>>> doing encryption and other setup - rather than net80211. This removes the >>>> need for the "TX lock" in the net80211 transmit path. >>>> >>>> I added this way back in 2011/2012 timeframe because I noticed that >>>> after the vap work, sometimes i'd get dropped packets / hung data streams. >>>> What was happening was the sequence numbers were assigned by net80211, but >>>> the encryption - and the encryption sequence IVs - were being done in the >>>> driver. This can happen concurrently across multiple CPUs, or even >>>> preempted on a single CPU. It wasn't a problem on earlier single CPU setups >>>> because preemption wasn't as aggressive, and pre-VAP the encapsulation / >>>> encryption was actually done by the driver calling into net80211. >>>> >>>> I cheaped out and added that lock. It fixed it for everything, with the >>>> cost of concurrency performance and some LORs. >>>> >>>> So, my goal is to finally get rid of the lock entirely during -16. >>>> >>>> Secondly, the NULL data frame handling. This is something that has >>>> plagued things like iwn(4) forever, where the TX sequence number would get >>>> out of whack with the TX DMA ring (oh no I'm going into the weeds.) Anyway, >>>> it would cause the firmware to crash. A lot of NICs with firmware MACs >>>> actually generate their own NULL data frames so there's no need for us to >>>> do it. I've turned it off for a handful of NICs so we can test it out. >>>> >>>> Thanks! More to come once this settles. >>>> >>>> >>>> >>>> -adrian >>>> >>>> >>> >>> -- >>> Nuno Teixeira >>> FreeBSD UNIX: <eduardo@FreeBSD.org> Web: https://FreeBSD.org >>> >> > > -- > Nuno Teixeira > FreeBSD UNIX: <eduardo@FreeBSD.org> Web: https://FreeBSD.org >