Re: please update -head if you're running it - testing changes to NULL frames and sequence number offload

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
>