Date: Sat, 20 Sep 2025 21:42:31 +0100 From: Nuno Teixeira <eduardo@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-wireless <freebsd-wireless@freebsd.org> Subject: Re: please update -head if you're running it - testing changes to NULL frames and sequence number offload Message-ID: <CAFDf7U%2BKrE9JyCm-o_rNmZz0J1XXFcpu02q_QGyhgMFkXo3gJw@mail.gmail.com> In-Reply-To: <CAJ-Vmo=FRWaS9TvnevZP27tGqiC3rBYn5Y6yZiig=L5Jw2sz9A@mail.gmail.com> References: <CAJ-VmomiSP9ozQTbmQioMMWpthzpajaO2FUavMSiydN4ob7Okw@mail.gmail.com> <CAFDf7UL%2B6tcno=t6%2BTYFn1E-j62J97SdUZ_jvS==CX1q8eD2LA@mail.gmail.com> <CAJ-Vmo=FRWaS9TvnevZP27tGqiC3rBYn5Y6yZiig=L5Jw2sz9A@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] <div dir="ltr">Ok, after reverting 5bf3c55 how do I quick compile it to avoid compile entire kernel?</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Adrian Chadd <<a href="mailto:adrian@freebsd.org">adrian@freebsd.org</a>> escreveu (sábado, 20/09/2025 à(s) 20:13):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 20 Sept 2025 at 12:04, Nuno Teixeira <<a href="mailto:eduardo@freebsd.org" target="_blank">eduardo@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Hello Adrian!<br><br></div>I'm using iwx driver on my AX201 for some months and I saw it as stable on my laptop.<br></div>(switching to iwlwifi, I saw that connection rate becomes degradated after some hours, and some crashes too)<br><br></div>I'm using main 20250920-e043af9ca596 . Today I upgraded to 20250920-31ec8b6407fd and iperf3 tests to my router failed:<br><div><br></div><div><div>- after failed iperf3, I need to restart servive netif to get internet back.</div><div>- nothing in messages, dmesg, no crash</div></div></div></blockquote><div><br></div><div>Hm. Yeah I saw some oddness like this, even before my work.</div><div><br></div><div>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.</div><div><br></div><div>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. :-)</div><div><br></div><div><br></div><div>commit 5bf3c5586b5e8256af0c1a6916fb5fdc6c70b3c9<br>Author: Adrian Chadd <adrian@FreeBSD.org><br>Date: Wed Jun 4 20:50:33 2025 -0700<br></div><div>iwx: enable seqno offload<br></div><div><br></div><div>Author: Adrian Chadd <adrian@FreeBSD.org><br>Date: Fri Aug 29 22:10:22 2025 -0700<br><br> [iwx] tell net80211 not to originate NULL data frames</div><div><br></div><div>Lemme know what you see!</div><div><br></div><div>Thanks!</div><div><br></div><div><br></div><div><br></div><div>-adrian</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div>iperf3 -c 192.168.1.1<br>Connecting to host 192.168.1.1, port 5201<br>[ 5] local 192.168.1.188 port 41996 connected to 192.168.1.1 port 5201<br>[ ID] Interval Transfer Bitrate Retr Cwnd<br>[ 5] 0.00-1.06 sec 3.75 MBytes 29.6 Mbits/sec 110 214 KBytes<br>[ 5] 1.06-2.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes<br>[ 5] 2.06-3.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes<br>[ 5] 3.06-4.03 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes<br>[ 5] 4.03-5.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes<br>[ 5] 5.06-6.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes<br>[ 5] 6.06-7.02 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes<br>[ 5] 7.02-8.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes<br><div>[ 5] 8.06-9.02 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes</div><div><br></div><div>- rolled back to latest BE:</div><div><br></div>iperf3 -c 192.168.1.1<br>Connecting to host 192.168.1.1, port 5201<br>[ 5] local 192.168.1.188 port 49619 connected to 192.168.1.1 port 5201<br>[ ID] Interval Transfer Bitrate Retr Cwnd<br>[ 5] 0.00-1.06 sec 2.88 MBytes 22.7 Mbits/sec 274 1.41 KBytes<br>[ 5] 1.06-2.00 sec 25.1 MBytes 224 Mbits/sec 79 280 KBytes<br>[ 5] 2.00-3.03 sec 31.6 MBytes 259 Mbits/sec 23 249 KBytes<br>[ 5] 3.03-4.06 sec 36.2 MBytes 295 Mbits/sec 2 263 KBytes<br>[ 5] 4.06-5.04 sec 35.2 MBytes 301 Mbits/sec 6 266 KBytes<br>[ 5] 5.04-6.03 sec 30.5 MBytes 259 Mbits/sec 3 236 KBytes<br>[ 5] 6.03-7.06 sec 31.6 MBytes 257 Mbits/sec 14 214 KBytes<br>[ 5] 7.06-8.06 sec 30.8 MBytes 259 Mbits/sec 0 368 KBytes<br>[ 5] 8.06-9.05 sec 30.6 MBytes 259 Mbits/sec 4 339 KBytes<br>[ 5] 9.05-10.01 sec 29.8 MBytes 260 Mbits/sec 2 330 KBytes<br>- - - - - - - - - - - - - - - - - - - - - - - - -<br>[ ID] Interval Transfer Bitrate Retr<br>[ 5] 0.00-10.01 sec 284 MBytes 238 Mbits/sec 407 sender<br><div>[ 5] 0.00-10.02 sec 284 MBytes 237 Mbits/sec receiver</div><div><br></div><div>Thanks,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Adrian Chadd <<a href="mailto:adrian@freebsd.org" target="_blank">adrian@freebsd.org</a>> escreveu (sábado, 20/09/2025 à(s) 01:55):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>hi!</div><div><br></div><div>I've been sitting on this for a while and noodling on the devices I have here.</div><div>If you're using -HEAD, please update and let me know if wifi is OK or not OK after today's commits.</div><div><br></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I cheaped out and added that lock. It fixed it for everything, with the cost of concurrency performance and some LORs.</div><div><br></div><div>So, my goal is to finally get rid of the lock entirely during -16.</div><div><br></div><div>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.</div><div><br></div><div>Thanks! More to come once this settles.</div><div><br></div><div><br></div><div><br></div><div>-adrian</div><div><br></div></div> </blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><font color="#888888">Nuno Teixeira</font></div><div><div><font color="#888888"> FreeBSD UNIX: <eduardo@FreeBSD.org> Web: <a href="https://FreeBSD.org" rel="noreferrer" target="_blank">https://FreeBSD.org</a><br></font></div></div></div></div>; </blockquote></div></div> </blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><font color="#888888">Nuno Teixeira</font></div><div><div><font color="#888888"> FreeBSD UNIX: <eduardo@FreeBSD.org> Web: <a href="https://FreeBSD.org" rel="noreferrer" target="_blank">https://FreeBSD.org</a><br></font></div></div></div></div>;home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7U%2BKrE9JyCm-o_rNmZz0J1XXFcpu02q_QGyhgMFkXo3gJw>