sysutils/pam_xdg: Cancelled on -CURRENT

2024-03-18 Thread Alastair Hogge
Hello, Recently a similar module (PAM) mentioned in the subject was committed to base[1]. The module in base masks the currently installed Port, the man page can be accessed with man -M /usr/local/share/man 8 pam_xdg, however, I can now no longer build the Port. I noticed that the base module has

Re: git: e34ea0196f44 - main - tcp: clear all TCP timers in tcp_timer_stop() when in callout

2024-03-18 Thread Gleb Smirnoff
Hi! This commit is supposed to fix a problem we do not have a reproducer for. The problem was that sometimes a TCP connection enters tcp_discardcb() with a scheduled timer. A temporary patch 57e27ff07aff was committed to mask the problem. This patch is supposed to fix the root cause. However,

Re: Request for Testing: TCP RACK

2024-03-18 Thread Drew Gallatin
No. The goal is to run on every return to userspace for every thread. Drew On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote: > On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > > I got the idea from > > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.

Re: Request for Testing: TCP RACK

2024-03-18 Thread Konstantin Belousov
On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > I got the idea from > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf > The gist is that the TCP pacing stuff needs to run frequently, and > rather than run it out of a clock interrupt, its more efficient to run

Re: Request for Testing: TCP RACK

2024-03-18 Thread Drew Gallatin
I got the idea from https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf The gist is that the TCP pacing stuff needs to run frequently, and rather than run it out of a clock interrupt, its more efficient to run it out of a system call context at just the point where we return

Re: Request for Testing: TCP RACK

2024-03-18 Thread Konstantin Belousov
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > >> > >> Hello all! > >> > >> It works just fine! > >> System performance is OK. > >> Using patch on main-n268841-b0aaf8beb126(

kernel= , kern.module_path= , and loader menu selections: how to have it always find the matching, say, nfsd.ko (same directory as the kernel)

2024-03-18 Thread Mark Millard
I'm using an aarch64 environment as the example context for this note. I have instances of the various PkgBase kernels and one or more personal kernel builds. Currently: # ls -Tlod /boot/kernel*/nfsd* -r--r--r-- 1 root wheel - 401600 Mar 17 18:45:35 2024 /boot/kernel.CA76-NODBG.good/nfsd.ko -r-

Re: Request for Testing: TCP RACK

2024-03-18 Thread David Wolfskill
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > ... > >> It would be so nice that we can have a sysctl tunnable for this patch > >> so we could do more tests without recompiling kernel. > > Thanks for testing! > > > > @gallatin: can you come up with a patch that is acceptable for Net

Re: Request for Testing: TCP RACK

2024-03-18 Thread Mike Karels
On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: >> >> Hello all! >> >> It works just fine! >> System performance is OK. >> Using patch on main-n268841-b0aaf8beb126(-dirty). >> >> --- >> net.inet.tcp.functions_available: >> Stack

Re: Request for Testing: TCP RACK

2024-03-18 Thread tuexen
> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > > Hello all! > > It works just fine! > System performance is OK. > Using patch on main-n268841-b0aaf8beb126(-dirty). > > --- > net.inet.tcp.functions_available: > Stack D AliasPCB count > f

Re: Request for Testing: TCP RACK

2024-03-18 Thread Nuno Teixeira
Hello all! It works just fine! System performance is OK. Using patch on main-n268841-b0aaf8beb126(-dirty). --- net.inet.tcp.functions_available: Stack D AliasPCB count freebsd freebsd 0 rack