Request for Testing: TCP RACK
Dear all, recently the main branch was changed to build the TCP RACK stack which is a loadable kernel module, by default: https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc As discussed on the bi-weekly transport call, it would be great if people could test the RACK stack for their workload. Please report any problems to the net@ mailing list or open an issue in the bug tracker and drop me a note via email. This includes regressions in CPU usage, regressions in performance or any other unexpected change you observe. You can load the kernel module using kldload tcp_rack You can make the RACK stack the default stack using sysctl net.inet.tcp.functions_default=rack Based on the feedback we get, the default stack might be switched to the RACK stack. Please let me know if you have any questions. Best regards Michael
[Bug 274715] [ktls] deadlock with mlx5 and KTLS receive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274715 --- Comment #8 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a592812327deaf69ab226afc5c8a01af43dc03c2 commit a592812327deaf69ab226afc5c8a01af43dc03c2 Author: Martin Matuska AuthorDate: 2023-11-13 13:29:27 + Commit: Martin Matuska CommitDate: 2023-11-16 11:17:41 + mlx5_core: fix deadlock when using RXTLS If removing a node of type FS_TYPE_FLOW_DEST we lock the flow group too late. This can lead to a deadlock with fs_add_dst_fg(). PR: 274715 MFC after: 1 week Reviewed by:kib Tested by: mm Differential Revision: https://reviews.freebsd.org/D42368 sys/dev/mlx5/mlx5_core/mlx5_fs_tree.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266356] Extra TCP stacks (RACK, BBR and TCP HTPS) are outdated in stable/13
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266356 Gordon Bergling changed: What|Removed |Added Resolution|--- |Overcome By Events Status|New |Closed -- You are receiving this mail because: You are the assignee for the bug.
Re: Request for Testing: TCP RACK
Hi, On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: > > Dear all, > > recently the main branch was changed to build the TCP RACK stack > which is a loadable kernel module, by default: > https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > > As discussed on the bi-weekly transport call, it would be great if people > could test the RACK stack for their workload. Please report any problems to > the > net@ mailing list or open an issue in the bug tracker and drop me a note via > email. > This includes regressions in CPU usage, regressions in performance or any > other > unexpected change you observe. > > You can load the kernel module using > kldload tcp_rack > > You can make the RACK stack the default stack using > sysctl net.inet.tcp.functions_default=rack > > Based on the feedback we get, the default stack might be switched to the > RACK stack. > > Please let me know if you have any questions. I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. # kldload tcp_rack kldload: an error occurred while loading module tcp_rack. Please check dmesg(8) for more details. In dmesg: KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type So you have to build a kernel with "options TCPHPTS" first? -- Herbert
Re: Request for Testing: TCP RACK
On Thu, 16 Nov 2023 13:06:03 +0100, "Herbert J. Skuhra" wrote: > > Hi, > > On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: > > > > Dear all, > > > > recently the main branch was changed to build the TCP RACK stack > > which is a loadable kernel module, by default: > > https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > > > > As discussed on the bi-weekly transport call, it would be great if people > > could test the RACK stack for their workload. Please report any problems to > > the > > net@ mailing list or open an issue in the bug tracker and drop me a note > > via email. > > This includes regressions in CPU usage, regressions in performance or any > > other > > unexpected change you observe. > > > > You can load the kernel module using > > kldload tcp_rack > > > > You can make the RACK stack the default stack using > > sysctl net.inet.tcp.functions_default=rack > > > > Based on the feedback we get, the default stack might be switched to the > > RACK stack. > > > > Please let me know if you have any questions. > > I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. > > # kldload tcp_rack > kldload: an error occurred while loading module tcp_rack. Please check > dmesg(8) for more details. > > In dmesg: > KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch > linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type > > So you have to build a kernel with "options TCPHPTS" first? OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". After setting "sysctl net.inet.tcp.functions_default=rack" git no longer works: # sysctl net.inet.tcp.functions_default=rack $ git pull client_loop: send disconnect: Broken pipe fatal: the remote end hung up upon initial contact # sysctl net.inet.tcp.functions_default=freebsd $ git pull Already up to date. -- Herbert
Re: Request for Testing: TCP RACK
On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote: > > OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". > > After setting "sysctl net.inet.tcp.functions_default=rack" git no > longer works: > > Are you using a fresh 15 head or a specific network setup ? Because I'm not able to reproduce your problem on my system: $ uname -a FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023 root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS amd64 $ cat /usr/src/sys/amd64/conf/TCPHPTS include GENERIC-NODEBUG ident TCPHPTS options TCPHPTS $ sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: rack $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working working $
Re: Request for Testing: TCP RACK
On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote: > > On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote: > > > > > OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". > > > > After setting "sysctl net.inet.tcp.functions_default=rack" git no > > longer works: > > > > > Are you using a fresh 15 head or a specific network setup ? > > Because I'm not able to reproduce your problem on my system: > > $ uname -a > FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0 > main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023 > root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS > amd64 > $ cat /usr/src/sys/amd64/conf/TCPHPTS > include GENERIC-NODEBUG > ident TCPHPTS > options TCPHPTS > $ sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: rack > $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working > working > $ OK, (g)it works if I disable pf. Do you use pf? -- Herbert
Re: Request for Testing: TCP RACK
> On Nov 16, 2023, at 13:06, Herbert J. Skuhra wrote: > > Hi, > > On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: >> >> Dear all, >> >> recently the main branch was changed to build the TCP RACK stack >> which is a loadable kernel module, by default: >> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc >> >> As discussed on the bi-weekly transport call, it would be great if people >> could test the RACK stack for their workload. Please report any problems to >> the >> net@ mailing list or open an issue in the bug tracker and drop me a note via >> email. >> This includes regressions in CPU usage, regressions in performance or any >> other >> unexpected change you observe. >> >> You can load the kernel module using >> kldload tcp_rack >> >> You can make the RACK stack the default stack using >> sysctl net.inet.tcp.functions_default=rack >> >> Based on the feedback we get, the default stack might be switched to the >> RACK stack. >> >> Please let me know if you have any questions. > > I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. > > # kldload tcp_rack > kldload: an error occurred while loading module tcp_rack. Please check > dmesg(8) for more details. > > In dmesg: > KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch > linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type > > So you have to build a kernel with "options TCPHPTS" first? Hi Herbert, yes this is correct. For whatever reason I was assuming the TCPHPTS is already enabled in all configs, but this is not correct. Will put up an review to do this tomorrow. Thanks for reporting. Best regards Michael > > -- > Herbert
Re: Request for Testing: TCP RACK
> On Nov 16, 2023, at 14:05, Herbert J. Skuhra wrote: > > On Thu, 16 Nov 2023 13:06:03 +0100, "Herbert J. Skuhra" wrote: >> >> Hi, >> >> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: >>> >>> Dear all, >>> >>> recently the main branch was changed to build the TCP RACK stack >>> which is a loadable kernel module, by default: >>> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc >>> >>> As discussed on the bi-weekly transport call, it would be great if people >>> could test the RACK stack for their workload. Please report any problems to >>> the >>> net@ mailing list or open an issue in the bug tracker and drop me a note >>> via email. >>> This includes regressions in CPU usage, regressions in performance or any >>> other >>> unexpected change you observe. >>> >>> You can load the kernel module using >>> kldload tcp_rack >>> >>> You can make the RACK stack the default stack using >>> sysctl net.inet.tcp.functions_default=rack >>> >>> Based on the feedback we get, the default stack might be switched to the >>> RACK stack. >>> >>> Please let me know if you have any questions. >> >> I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. >> >> # kldload tcp_rack >> kldload: an error occurred while loading module tcp_rack. Please check >> dmesg(8) for more details. >> >> In dmesg: >> KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch >> linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type >> >> So you have to build a kernel with "options TCPHPTS" first? > > OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". > > After setting "sysctl net.inet.tcp.functions_default=rack" git no > longer works: > > # sysctl net.inet.tcp.functions_default=rack > $ git pull > client_loop: send disconnect: Broken pipe > fatal: the remote end hung up upon initial contact > # sysctl net.inet.tcp.functions_default=freebsd > $ git pull > Already up to date. Interesting. It works on my development system: tuexen@head:~/freebsd-src % sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: rack tuexen@head:~/freebsd-src % git pull Already up to date. tuexen@head:~/freebsd-src % Could you provide a .pcapng file covering the `git pull` command? Best regards Michael > > -- > Herbert
Re: Request for Testing: TCP RACK
> On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote: > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote: >> >> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote: >> >>> >>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". >>> >>> After setting "sysctl net.inet.tcp.functions_default=rack" git no >>> longer works: >>> >>> >> Are you using a fresh 15 head or a specific network setup ? >> >> Because I'm not able to reproduce your problem on my system: >> >> $ uname -a >> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0 >> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023 >> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS >> amd64 >> $ cat /usr/src/sys/amd64/conf/TCPHPTS >> include GENERIC-NODEBUG >> ident TCPHPTS >> options TCPHPTS >> $ sysctl net.inet.tcp.functions_default >> net.inet.tcp.functions_default: rack >> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working >> working >> $ > > OK, (g)it works if I disable pf. Do you use pf? Can you share your pf config such that I can reproduce the problem locally? Best regards Michael > > -- > Herbert
[Bug 275146] odd error handling from net.inet.tcp.functions_default sysctl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275146 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
