Panic testing ZFS raidz expansion feature.

2024-07-19 Thread Maurizio Vairani
I want to test the ZFS raidz expansion feature.
I have create a VM with vm-bhyve:
# vm iso
https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/15.0/FreeBSD-15.0-CURRENT-amd64-20240718-a4469a0d19b6-271237-bootonly.iso
# vm create fbsd15-bis
I have increased the VM memory to 2G:
# cat fbsd15-bis.conf
loader="bhyveload"
cpu=1
memory=2G
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="disk0.img"
uuid="ff66b6cc-459e-11ef-92b1-c86000cc94af"
network0_mac="58:9c:fc:0a:ad:da"

# vm install fbsd15-bis
FreeBSD-15.0-CURRENT-amd64-20240718-a4469a0d19b6-271237-bootonly.iso
After the installation I have create 3 additional disks:
in the host:
# truncate -s 10G disk1.img
# truncate -s 10G disk2.img
# truncate -s 10G disk3.img
I have added 3 additional disk:
# cat fbsd15-bis.conf
loader="bhyveload"
cpu=1
memory=2G
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="disk0.img"
disk1_type="virtio-blk"
disk1_name="disk1.img"
disk2_type="virtio-blk"
disk2_name="disk2.img"
disk3_type="virtio-blk"
disk3_name="disk3.img"
uuid="ff66b6cc-459e-11ef-92b1-c86000cc94af"
network0_mac="58:9c:fc:0a:ad:da"
# vm start fbsd15-bis

in the VM:
# zpool create tank raidz1 vtbd1 vtbd2
# zpool attach tank raidz1-0 vtbd3
panic: VERIFY(vd == vd->vdev_top) failed

cpuid = 0
time = 1721375688
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00546d1800
vpanic() at vpanic+0x13f/frame 0xfe00546d1930
spl_panic() at spl_panic+0x3a/frame 0xfe00546d1990
zio_vdev_io_start() at zio_vdev_io_start+0x637/frame 0xfe00546d19e0
zio_nowait() at zio_nowait+0x10c/frame 0xfe00546d1a20
vdev_check_boot_reserve() at vdev_check_boot_reserve+0x7a/frame
0xfe00546d1a50
spa_vdev_attach() at spa_vdev_attach+0x700/frame 0xfe00546d1ad0
zfs_ioc_vdev_attach() at zfs_ioc_vdev_attach+0x75/frame 0xfe00546d1b10
zfsdev_ioctl_common() at zfsdev_ioctl_common+0x4f4/frame 0xfe00546d1bd0
zfsdev_ioctl() at zfsdev_ioctl+0xfb/frame 0xfe00546d1c00
devfs_ioctl() at devfs_ioctl+0xd1/frame 0xfe00546d1c50
vn_ioctl() at vn_ioctl+0xbc/frame 0xfe00546d1cc0
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe00546d1ce0
kern_ioctl() at kern_ioctl+0x286/frame 0xfe00546d1d40
sys_ioctl() at sys_ioctl+0x12d/frame 0xfe00546d1e00
amd64_syscall() at amd64_syscall+0x158/frame 0xfe00546d1f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00546d1f30
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0xb2fddfff8fa, rsp =
0xb2fcf7fe8d8, rbp = 0xb2fcf7fe940 ---
KDB: enter: panic
[ thread pid 958 tid 100176 ]
Stopped at  kdb_enter+0x33: movq$0,0x1058552(%rip)

--
Regards,
Maurizio


Re: Request for Testing: TCP RACK

2024-04-10 Thread Nuno Teixeira
pts).
>> >>
>> >> Drew
>> >>
>> >> On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote:
>> >>> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
>> >>>> Ok I have created
>> >>>>
>> >>>> https://reviews.freebsd.org/D44420
>> >>>>
>> >>>>
>> >>>> To address the issue. I also attach a short version of the patch
>> that Nuno
>> >>>> can try and validate
>> >>>>
>> >>>> it works. Drew you may want to try this and validate the
>> optimization does
>> >>>> kick in since I can
>> >>>>
>> >>>> only now test that it does not on my local box :)
>> >>> The patch still causes access to all cpu's cachelines on each userret.
>> >>> It would be much better to inc/check the threshold and only schedule
>> the
>> >>> call when exceeded.  Then the call can occur in some dedicated
>> context,
>> >>> like per-CPU thread, instead of userret.
>> >>>
>> >>>>
>> >>>>
>> >>>> R
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 3/18/24 3:42 PM, Drew Gallatin wrote:
>> >>>>> 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.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
>> to
>> >>>>>>> userspace and the cache is trashed anyway. The current
>> implementation
>> >>>>>>> is fine for our workload, but probably not idea for a generic
>> system.
>> >>>>>>> Especially one where something is banging on system calls.
>> >>>>>>>
>> >>>>>>> Ast's could be the right tool for this, but I'm super unfamiliar
>> with
>> >>>>>>> them, and I can't find any docs on them.
>> >>>>>>>
>> >>>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent
>> to
>> >>>>>>> what's happening here?
>> >>>>>> This call would need some AST number added, and then it registers
>> the
>> >>>>>> ast to run on next return to userspace, for the current thread.
>> >>>>>>
>> >>>>>> Is it enough?
>> >>>>>>>
>> >>>>>>> Drew
>> >>>>>>
>> >>>>>>>
>> >>>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
>> >>>>>>>> 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(-dirty).
>> >>>>>>>>>>>
>> >>>>>>>>>>> ---
>> >>>>>>>>>>> net.inet.tcp.functions_available:
>> >>>>>>>>>>> Stack   D
>> >>>>>> AliasPCB count
>> >>>>>>>>>>> freebsd freebsd  0
>> >>>>>>>>>>> rack

Re: Request for Testing: TCP RACK

2024-04-10 Thread Nuno Teixeira
> >>>> kick in since I can
> >>>>
> >>>> only now test that it does not on my local box :)
> >>> The patch still causes access to all cpu's cachelines on each userret.
> >>> It would be much better to inc/check the threshold and only schedule
> the
> >>> call when exceeded.  Then the call can occur in some dedicated context,
> >>> like per-CPU thread, instead of userret.
> >>>
> >>>>
> >>>>
> >>>> R
> >>>>
> >>>>
> >>>>
> >>>> On 3/18/24 3:42 PM, Drew Gallatin wrote:
> >>>>> 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.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
> to
> >>>>>>> userspace and the cache is trashed anyway. The current
> implementation
> >>>>>>> is fine for our workload, but probably not idea for a generic
> system.
> >>>>>>> Especially one where something is banging on system calls.
> >>>>>>>
> >>>>>>> Ast's could be the right tool for this, but I'm super unfamiliar
> with
> >>>>>>> them, and I can't find any docs on them.
> >>>>>>>
> >>>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent
> to
> >>>>>>> what's happening here?
> >>>>>> This call would need some AST number added, and then it registers
> the
> >>>>>> ast to run on next return to userspace, for the current thread.
> >>>>>>
> >>>>>> Is it enough?
> >>>>>>>
> >>>>>>> Drew
> >>>>>>
> >>>>>>>
> >>>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> >>>>>>>> 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(-dirty).
> >>>>>>>>>>>
> >>>>>>>>>>> ---
> >>>>>>>>>>> net.inet.tcp.functions_available:
> >>>>>>>>>>> Stack   D
> >>>>>> AliasPCB count
> >>>>>>>>>>> freebsd freebsd  0
> >>>>>>>>>>> rack*
> >>>>>> rack 38
> >>>>>>>>>>> ---
> >>>>>>>>>>>
> >>>>>>>>>>> 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 Netflix
> >>>>>>>>>> and allows to mitigate the performance regression.
> >>>>>>>>>
> >>>>>>>>> Ideally, tcphpts could enable this automatically when it
> >>&

Re: Request for Testing: TCP RACK

2024-04-10 Thread tuexen
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.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 to
>>>>>>> userspace and the cache is trashed anyway. The current implementation
>>>>>>> is fine for our workload, but probably not idea for a generic system.
>>>>>>> Especially one where something is banging on system calls.
>>>>>>> 
>>>>>>> Ast's could be the right tool for this, but I'm super unfamiliar with
>>>>>>> them, and I can't find any docs on them.
>>>>>>> 
>>>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
>>>>>>> what's happening here?
>>>>>> This call would need some AST number added, and then it registers the
>>>>>> ast to run on next return to userspace, for the current thread.
>>>>>> 
>>>>>> Is it enough?
>>>>>>> 
>>>>>>> Drew
>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
>>>>>>>> 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(-dirty).
>>>>>>>>>>> 
>>>>>>>>>>> ---
>>>>>>>>>>> net.inet.tcp.functions_available:
>>>>>>>>>>> Stack   D
>>>>>> AliasPCB count
>>>>>>>>>>> freebsd freebsd  0
>>>>>>>>>>> rack*
>>>>>> rack 38
>>>>>>>>>>> ---
>>>>>>>>>>> 
>>>>>>>>>>> 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 Netflix
>>>>>>>>>> and allows to mitigate the performance regression.
>>>>>>>>> 
>>>>>>>>> Ideally, tcphpts could enable this automatically when it
>>>>>> starts to be
>>>>>>>>> used (enough?), but a sysctl could select auto/on/off.
>>>>>>>> There is already a well-known mechanism to request execution of the
>>>>>>>> specific function on return to userspace, namely AST.  The difference
>>>>>>>> with the current hack is that the execution is requested for one
>>>>>> callback
>>>>>>>> in the context of the specific thread.
>>>>>>>> 
>>>>>>>> Still, it might be worth a try to use it; what is the reason to
>>>>>> hit a thread
>>>>>>>> that does not do networking, with TCP processing?
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Mike
>>>>>>>>> 
>>>>>>>>>> Best regards
>>>>>>>>>> Michael
>>>>>>>>>>> 
>>>>>>>>>>> Thanks all!
>>>>>>>>>>> Really happy here :)
>>>

Re: Request for Testing: TCP RACK

2024-04-10 Thread Nuno Teixeira
 a system call context at just the point where we return to
> >>>>>> userspace and the cache is trashed anyway. The current
> implementation
> >>>>>> is fine for our workload, but probably not idea for a generic
> system.
> >>>>>> Especially one where something is banging on system calls.
> >>>>>>
> >>>>>> Ast's could be the right tool for this, but I'm super unfamiliar
> with
> >>>>>> them, and I can't find any docs on them.
> >>>>>>
> >>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
> >>>>>> what's happening here?
> >>>>> This call would need some AST number added, and then it registers the
> >>>>> ast to run on next return to userspace, for the current thread.
> >>>>>
> >>>>> Is it enough?
> >>>>>>
> >>>>>> Drew
> >>>>>
> >>>>>>
> >>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> >>>>>>> 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(-dirty).
> >>>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> net.inet.tcp.functions_available:
> >>>>>>>>>> Stack   D
> >>>>> AliasPCB count
> >>>>>>>>>> freebsd freebsd  0
> >>>>>>>>>> rack*
> >>>>> rack 38
> >>>>>>>>>> ---
> >>>>>>>>>>
> >>>>>>>>>> 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 Netflix
> >>>>>>>>> and allows to mitigate the performance regression.
> >>>>>>>>
> >>>>>>>> Ideally, tcphpts could enable this automatically when it
> >>>>> starts to be
> >>>>>>>> used (enough?), but a sysctl could select auto/on/off.
> >>>>>>> There is already a well-known mechanism to request execution of the
> >>>>>>> specific function on return to userspace, namely AST.  The
> difference
> >>>>>>> with the current hack is that the execution is requested for one
> >>>>> callback
> >>>>>>> in the context of the specific thread.
> >>>>>>>
> >>>>>>> Still, it might be worth a try to use it; what is the reason to
> >>>>> hit a thread
> >>>>>>> that does not do networking, with TCP processing?
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Mike
> >>>>>>>>
> >>>>>>>>> Best regards
> >>>>>>>>> Michael
> >>>>>>>>>>
> >>>>>>>>>> Thanks all!
> >>>>>>>>>> Really happy here :)
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>
> >>>>>>>>>> Nuno Teixeira  escreveu (domingo,
> >>>>> 17/03/2024 à(s) 20:26):
> >>>>>>>>>>>
> >>>>>>>>>>> Hello,
> >>>>>>>>>>>
> >>>>

Re: Request for Testing: TCP RACK

2024-03-28 Thread tuexen
> On 28. Mar 2024, at 15:00, Nuno Teixeira  wrote:
> 
> Hello all!
> 
> Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!
> 
> Thanks all!
Thanks for the feedback!

Best regards
Michael
> 
> Drew Gallatin  escreveu (quinta, 21/03/2024 à(s) 12:58):
> The entire point is to *NOT* go through the overhead of scheduling something 
> asynchronously, but to take advantage of the fact that a user/kernel 
> transition is going to trash the cache anyway.
> 
> In the common case of a system which has less than the threshold  number of 
> connections , we access the tcp_hpts_softclock function pointer, make one 
> function call, and access hpts_that_need_softclock, and then return.  So 
> that's 2 variables and a function call.
> 
> I think it would be preferable to avoid that call, and to move the 
> declaration of tcp_hpts_softclock and hpts_that_need_softclock so that they 
> are in the same cacheline.  Then we'd be hitting just a single line in the 
> common case.  (I've made comments on the review to that effect).
> 
> Also, I wonder if the threshold could get higher by default, so that hpts is 
> never called in this context unless we're to the point where we're scheduling 
> thousands of runs of the hpts thread (and taking all those clock interrupts).
> 
> Drew
> 
> On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote:
>> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
>>> Ok I have created
>>> 
>>> https://reviews.freebsd.org/D44420
>>> 
>>> 
>>> To address the issue. I also attach a short version of the patch that Nuno
>>> can try and validate
>>> 
>>> it works. Drew you may want to try this and validate the optimization does
>>> kick in since I can
>>> 
>>> only now test that it does not on my local box :)
>> The patch still causes access to all cpu's cachelines on each userret.
>> It would be much better to inc/check the threshold and only schedule the
>> call when exceeded.  Then the call can occur in some dedicated context,
>> like per-CPU thread, instead of userret.
>> 
>>> 
>>> 
>>> R
>>> 
>>> 
>>> 
>>> On 3/18/24 3:42 PM, Drew Gallatin wrote:
>>>> 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.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 to
>>>>>> userspace and the cache is trashed anyway. The current implementation
>>>>>> is fine for our workload, but probably not idea for a generic system.
>>>>>> Especially one where something is banging on system calls.
>>>>>> 
>>>>>> Ast's could be the right tool for this, but I'm super unfamiliar with
>>>>>> them, and I can't find any docs on them.
>>>>>> 
>>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
>>>>>> what's happening here?
>>>>> This call would need some AST number added, and then it registers the
>>>>> ast to run on next return to userspace, for the current thread.
>>>>> 
>>>>> Is it enough?
>>>>>> 
>>>>>> Drew
>>>>> 
>>>>>> 
>>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
>>>>>>> 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(-dirty).
>>>>>>>>>> 
>>>>>>>>>> ---
>>>>>>

Re: Request for Testing: TCP RACK

2024-03-28 Thread Nuno Teixeira
Hello all!

Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop
(amd64)!

Thanks all!

Drew Gallatin  escreveu (quinta, 21/03/2024 à(s)
12:58):

> The entire point is to *NOT* go through the overhead of scheduling
> something asynchronously, but to take advantage of the fact that a
> user/kernel transition is going to trash the cache anyway.
>
> In the common case of a system which has less than the threshold  number
> of connections , we access the tcp_hpts_softclock function pointer, make
> one function call, and access hpts_that_need_softclock, and then return.
> So that's 2 variables and a function call.
>
> I think it would be preferable to avoid that call, and to move the
> declaration of tcp_hpts_softclock and hpts_that_need_softclock so that they
> are in the same cacheline.  Then we'd be hitting just a single line in the
> common case.  (I've made comments on the review to that effect).
>
> Also, I wonder if the threshold could get higher by default, so that hpts
> is never called in this context unless we're to the point where we're
> scheduling thousands of runs of the hpts thread (and taking all those clock
> interrupts).
>
> Drew
>
> On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote:
>
> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> > Ok I have created
> >
> > https://reviews.freebsd.org/D44420
> >
> >
> > To address the issue. I also attach a short version of the patch that
> Nuno
> > can try and validate
> >
> > it works. Drew you may want to try this and validate the optimization
> does
> > kick in since I can
> >
> > only now test that it does not on my local box :)
> The patch still causes access to all cpu's cachelines on each userret.
> It would be much better to inc/check the threshold and only schedule the
> call when exceeded.  Then the call can occur in some dedicated context,
> like per-CPU thread, instead of userret.
>
> >
> >
> > R
> >
> >
> >
> > On 3/18/24 3:42 PM, Drew Gallatin wrote:
> > > 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.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
> to
> > > > > userspace and the cache is trashed anyway. The current
> implementation
> > > > > is fine for our workload, but probably not idea for a generic
> system.
> > > > > Especially one where something is banging on system calls.
> > > > >
> > > > > Ast's could be the right tool for this, but I'm super unfamiliar
> with
> > > > > them, and I can't find any docs on them.
> > > > >
> > > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent
> to
> > > > > what's happening here?
> > > > This call would need some AST number added, and then it registers the
> > > > ast to run on next return to userspace, for the current thread.
> > > >
> > > > Is it enough?
> > > > >
> > > > > Drew
> > > >
> > > > >
> > > > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> > > > > > 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(-dirty).
> > > > > > > >>
> > > > > > > >> ---
> > > > > > > >> net.inet.tcp.functions_available:
> > > > > > > >> Stack   D
> > > > Alias  

Re: Request for Testing: TCP RACK

2024-03-21 Thread Drew Gallatin
The entire point is to *NOT* go through the overhead of scheduling something 
asynchronously, but to take advantage of the fact that a user/kernel transition 
is going to trash the cache anyway.

In the common case of a system which has less than the threshold  number of 
connections , we access the tcp_hpts_softclock function pointer, make one 
function call, and access hpts_that_need_softclock, and then return.  So that's 
2 variables and a function call.

I think it would be preferable to avoid that call, and to move the declaration 
of tcp_hpts_softclock and hpts_that_need_softclock so that they are in the same 
cacheline.  Then we'd be hitting just a single line in the common case.  (I've 
made comments on the review to that effect).

Also, I wonder if the threshold could get higher by default, so that hpts is 
never called in this context unless we're to the point where we're scheduling 
thousands of runs of the hpts thread (and taking all those clock interrupts).

Drew

On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote:
> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> > Ok I have created
> > 
> > https://reviews.freebsd.org/D44420
> > 
> > 
> > To address the issue. I also attach a short version of the patch that Nuno
> > can try and validate
> > 
> > it works. Drew you may want to try this and validate the optimization does
> > kick in since I can
> > 
> > only now test that it does not on my local box :)
> The patch still causes access to all cpu's cachelines on each userret.
> It would be much better to inc/check the threshold and only schedule the
> call when exceeded.  Then the call can occur in some dedicated context,
> like per-CPU thread, instead of userret.
> 
> > 
> > 
> > R
> > 
> > 
> > 
> > On 3/18/24 3:42 PM, Drew Gallatin wrote:
> > > 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.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 to
> > > > > userspace and the cache is trashed anyway. The current implementation
> > > > > is fine for our workload, but probably not idea for a generic system.
> > > > > Especially one where something is banging on system calls.
> > > > >
> > > > > Ast's could be the right tool for this, but I'm super unfamiliar with
> > > > > them, and I can't find any docs on them.
> > > > >
> > > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
> > > > > what's happening here?
> > > > This call would need some AST number added, and then it registers the
> > > > ast to run on next return to userspace, for the current thread.
> > > > 
> > > > Is it enough?
> > > > >
> > > > > Drew
> > > > 
> > > > >
> > > > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> > > > > > 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(-dirty).
> > > > > > > >>
> > > > > > > >> ---
> > > > > > > >> net.inet.tcp.functions_available:
> > > > > > > >> Stack   D
> > > > AliasPCB count
> > > > > > > >> freebsd freebsd  0
> > > > > > > >> rack*
> > > > rack 38
> > > > > > > >> ---
> &g

Re: Request for Testing: TCP RACK

2024-03-20 Thread Konstantin Belousov
On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> Ok I have created
> 
> https://reviews.freebsd.org/D44420
> 
> 
> To address the issue. I also attach a short version of the patch that Nuno
> can try and validate
> 
> it works. Drew you may want to try this and validate the optimization does
> kick in since I can
> 
> only now test that it does not on my local box :)
The patch still causes access to all cpu's cachelines on each userret.
It would be much better to inc/check the threshold and only schedule the
call when exceeded.  Then the call can occur in some dedicated context,
like per-CPU thread, instead of userret.

> 
> 
> R
> 
> 
> 
> On 3/18/24 3:42 PM, Drew Gallatin wrote:
> > 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.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 to
> > > > userspace and the cache is trashed anyway. The current implementation
> > > > is fine for our workload, but probably not idea for a generic system.
> > > > Especially one where something is banging on system calls.
> > > >
> > > > Ast's could be the right tool for this, but I'm super unfamiliar with
> > > > them, and I can't find any docs on them.
> > > >
> > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
> > > > what's happening here?
> > > This call would need some AST number added, and then it registers the
> > > ast to run on next return to userspace, for the current thread.
> > > 
> > > Is it enough?
> > > >
> > > > Drew
> > > 
> > > >
> > > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> > > > > 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(-dirty).
> > > > > > >>
> > > > > > >> ---
> > > > > > >> net.inet.tcp.functions_available:
> > > > > > >> Stack   D
> > > Alias    PCB count
> > > > > > >> freebsd freebsd  0
> > > > > > >> rack    *
> > > rack 38
> > > > > > >> ---
> > > > > > >>
> > > > > > >> 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 Netflix
> > > > > > > and allows to mitigate the performance regression.
> > > > > >
> > > > > > Ideally, tcphpts could enable this automatically when it
> > > starts to be
> > > > > > used (enough?), but a sysctl could select auto/on/off.
> > > > > There is already a well-known mechanism to request execution of the
> > > > > specific function on return to userspace, namely AST.  The difference
> > > > > with the current hack is that the execution is requested for one
> > > callback
> > > > > in the context of the specific thread.
> > > > >
> > > > > Still, it might be worth a try to use it; what is the reason to
> > > hit a thread
> > > > > that does not do networking, with TCP processing?
> > > > >
> > > > > >
> > > > >

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.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 to
> > userspace and the cache is trashed anyway. The current implementation
> > is fine for our workload, but probably not idea for a generic system.
> > Especially one where something is banging on system calls.
> >
> > Ast's could be the right tool for this, but I'm super unfamiliar with
> > them, and I can't find any docs on them.
> >
> > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
> > what's happening here?
> This call would need some AST number added, and then it registers the
> ast to run on next return to userspace, for the current thread.
> 
> Is it enough?
> >
> > Drew
> 
> > 
> > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> > > 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(-dirty).
> > > > >>
> > > > >> ---
> > > > >> net.inet.tcp.functions_available:
> > > > >> Stack   D Alias
> > > > >> PCB count
> > > > >> freebsd   freebsd  0
> > > > >> rack* rack 38
> > > > >> ---
> > > > >>
> > > > >> 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 Netflix
> > > > > and allows to mitigate the performance regression.
> > > > 
> > > > Ideally, tcphpts could enable this automatically when it starts to be
> > > > used (enough?), but a sysctl could select auto/on/off.
> > > There is already a well-known mechanism to request execution of the
> > > specific function on return to userspace, namely AST.  The difference
> > > with the current hack is that the execution is requested for one callback
> > > in the context of the specific thread.
> > > 
> > > Still, it might be worth a try to use it; what is the reason to hit a 
> > > thread
> > > that does not do networking, with TCP processing?
> > > 
> > > > 
> > > > Mike
> > > > 
> > > > > Best regards
> > > > > Michael
> > > > >>
> > > > >> Thanks all!
> > > > >> Really happy here :)
> > > > >>
> > > > >> Cheers,
> > > > >>
> > > > >> Nuno Teixeira  escreveu (domingo, 17/03/2024 
> > > > >> à(s) 20:26):
> > > > >>>
> > > > >>> Hello,
> > > > >>>
> > > > >>>> I don't have the full context, but it seems like the complaint is 
> > > > >>>> a performance regression in bonnie++ and perhaps other things when 
> > > > >>>> tcp_hpts is loaded, even when it is not used.  Is that correct?
> > > > >>>>
> > > > >>>> If so, I suspect its because we drive the tcp_hpts_softclock() 
> > > > >>>> routine from userret(), in order to avoid tons of timer interrupts 
> > > > >>>> and context switches.  To test this theory,  you could apply a 
> > > > >>>> patch like:
> > > > >>>
> > > > >>> It's affecting overall system performance, bonnie was just a way to
> > > > >>> get some numbers to compare.
> > > > >>>
> > > > >>> Tomorrow I will test patch.
> > > > >>>
> > > > >>> Thanks!
> > > > >>>
> > > > >>> --
> > > > >>> Nuno Teixeira
> > > > >>> FreeBSD Committer (ports)
> > > > >>
> > > > >>
> > > > >>
> > > > >> -- 
> > > > >> Nuno Teixeira
> > > > >> FreeBSD Committer (ports)
> > > > 
> > > 
> 


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
> it out of a system call context at just the point where we return to
> userspace and the cache is trashed anyway. The current implementation
> is fine for our workload, but probably not idea for a generic system.
> Especially one where something is banging on system calls.
>
> Ast's could be the right tool for this, but I'm super unfamiliar with
> them, and I can't find any docs on them.
>
> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
> what's happening here?
This call would need some AST number added, and then it registers the
ast to run on next return to userspace, for the current thread.

Is it enough?
>
> Drew

> 
> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> > 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(-dirty).
> > > >>
> > > >> ---
> > > >> net.inet.tcp.functions_available:
> > > >> Stack   D AliasPCB 
> > > >> count
> > > >> freebsd   freebsd      0
> > > >> rack* rack 38
> > > >> ---
> > > >>
> > > >> 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 Netflix
> > > > and allows to mitigate the performance regression.
> > > 
> > > Ideally, tcphpts could enable this automatically when it starts to be
> > > used (enough?), but a sysctl could select auto/on/off.
> > There is already a well-known mechanism to request execution of the
> > specific function on return to userspace, namely AST.  The difference
> > with the current hack is that the execution is requested for one callback
> > in the context of the specific thread.
> > 
> > Still, it might be worth a try to use it; what is the reason to hit a thread
> > that does not do networking, with TCP processing?
> > 
> > > 
> > > Mike
> > > 
> > > > Best regards
> > > > Michael
> > > >>
> > > >> Thanks all!
> > > >> Really happy here :)
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Nuno Teixeira  escreveu (domingo, 17/03/2024 à(s) 
> > > >> 20:26):
> > > >>>
> > > >>> Hello,
> > > >>>
> > > >>>> I don't have the full context, but it seems like the complaint is a 
> > > >>>> performance regression in bonnie++ and perhaps other things when 
> > > >>>> tcp_hpts is loaded, even when it is not used.  Is that correct?
> > > >>>>
> > > >>>> If so, I suspect its because we drive the tcp_hpts_softclock() 
> > > >>>> routine from userret(), in order to avoid tons of timer interrupts 
> > > >>>> and context switches.  To test this theory,  you could apply a patch 
> > > >>>> like:
> > > >>>
> > > >>> It's affecting overall system performance, bonnie was just a way to
> > > >>> get some numbers to compare.
> > > >>>
> > > >>> Tomorrow I will test patch.
> > > >>>
> > > >>> Thanks!
> > > >>>
> > > >>> --
> > > >>> Nuno Teixeira
> > > >>> FreeBSD Committer (ports)
> > > >>
> > > >>
> > > >>
> > > >> -- 
> > > >> Nuno Teixeira
> > > >> FreeBSD Committer (ports)
> > > 
> > 



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 to userspace and the cache is trashed 
anyway.   The current implementation is fine for our workload, but probably not 
idea for a generic system.  Especially one where something is banging on system 
calls.  

Ast's could be the right tool for this, but I'm super unfamiliar with them, and 
I can't find any docs on them. 

Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to what's 
happening here?

Drew

On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> 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(-dirty).
> > >>
> > >> ---
> > >> net.inet.tcp.functions_available:
> > >> Stack   D AliasPCB 
> > >> count
> > >> freebsd   freebsd  0
> > >> rack* rack     38
> > >> ---
> > >>
> > >> 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 Netflix
> > > and allows to mitigate the performance regression.
> > 
> > Ideally, tcphpts could enable this automatically when it starts to be
> > used (enough?), but a sysctl could select auto/on/off.
> There is already a well-known mechanism to request execution of the
> specific function on return to userspace, namely AST.  The difference
> with the current hack is that the execution is requested for one callback
> in the context of the specific thread.
> 
> Still, it might be worth a try to use it; what is the reason to hit a thread
> that does not do networking, with TCP processing?
> 
> > 
> > Mike
> > 
> > > Best regards
> > > Michael
> > >>
> > >> Thanks all!
> > >> Really happy here :)
> > >>
> > >> Cheers,
> > >>
> > >> Nuno Teixeira  escreveu (domingo, 17/03/2024 à(s) 
> > >> 20:26):
> > >>>
> > >>> Hello,
> > >>>
> > >>>> I don't have the full context, but it seems like the complaint is a 
> > >>>> performance regression in bonnie++ and perhaps other things when 
> > >>>> tcp_hpts is loaded, even when it is not used.  Is that correct?
> > >>>>
> > >>>> If so, I suspect its because we drive the tcp_hpts_softclock() routine 
> > >>>> from userret(), in order to avoid tons of timer interrupts and context 
> > >>>> switches.  To test this theory,  you could apply a patch like:
> > >>>
> > >>> It's affecting overall system performance, bonnie was just a way to
> > >>> get some numbers to compare.
> > >>>
> > >>> Tomorrow I will test patch.
> > >>>
> > >>> Thanks!
> > >>>
> > >>> --
> > >>> Nuno Teixeira
> > >>> FreeBSD Committer (ports)
> > >>
> > >>
> > >>
> > >> -- 
> > >> Nuno Teixeira
> > >> FreeBSD Committer (ports)
> > 
> 


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(-dirty).
> >>
> >> ---
> >> net.inet.tcp.functions_available:
> >> Stack   D AliasPCB 
> >> count
> >> freebsd   freebsd  0
> >> rack* rack 38
> >> ---
> >>
> >> 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 Netflix
> > and allows to mitigate the performance regression.
> 
> Ideally, tcphpts could enable this automatically when it starts to be
> used (enough?), but a sysctl could select auto/on/off.
There is already a well-known mechanism to request execution of the
specific function on return to userspace, namely AST.  The difference
with the current hack is that the execution is requested for one callback
in the context of the specific thread.

Still, it might be worth a try to use it; what is the reason to hit a thread
that does not do networking, with TCP processing?

> 
>   Mike
> 
> > Best regards
> > Michael
> >>
> >> Thanks all!
> >> Really happy here :)
> >>
> >> Cheers,
> >>
> >> Nuno Teixeira  escreveu (domingo, 17/03/2024 à(s) 
> >> 20:26):
> >>>
> >>> Hello,
> >>>
> >>>> I don't have the full context, but it seems like the complaint is a 
> >>>> performance regression in bonnie++ and perhaps other things when 
> >>>> tcp_hpts is loaded, even when it is not used.  Is that correct?
> >>>>
> >>>> If so, I suspect its because we drive the tcp_hpts_softclock() routine 
> >>>> from userret(), in order to avoid tons of timer interrupts and context 
> >>>> switches.  To test this theory,  you could apply a patch like:
> >>>
> >>> It's affecting overall system performance, bonnie was just a way to
> >>> get some numbers to compare.
> >>>
> >>> Tomorrow I will test patch.
> >>>
> >>> Thanks!
> >>>
> >>> --
> >>> Nuno Teixeira
> >>> FreeBSD Committer (ports)
> >>
> >>
> >>
> >> -- 
> >> Nuno Teixeira
> >> FreeBSD Committer (ports)
> 



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 Netflix
> > and allows to mitigate the performance regression.
> 
> Ideally, tcphpts could enable this automatically when it starts to be
> used (enough?), but a sysctl could select auto/on/off.
> 
>   Mike
> 

Or (at some risk of over-{complicat,engineer}ing things), perhaps
sysctl/tunable for high- and low-water marks?

Peace,
david   (who is quite unlikely to be writing the code, so "grain of salt")
-- 
David H. Wolfskill  da...@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


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   D AliasPCB count
>> freebsd   freebsd  0
>> rack* rack 38
>> ---
>>
>> 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 Netflix
> and allows to mitigate the performance regression.

Ideally, tcphpts could enable this automatically when it starts to be
used (enough?), but a sysctl could select auto/on/off.

Mike

> Best regards
> Michael
>>
>> Thanks all!
>> Really happy here :)
>>
>> Cheers,
>>
>> Nuno Teixeira  escreveu (domingo, 17/03/2024 à(s) 
>> 20:26):
>>>
>>> Hello,
>>>
>>>> I don't have the full context, but it seems like the complaint is a 
>>>> performance regression in bonnie++ and perhaps other things when tcp_hpts 
>>>> is loaded, even when it is not used.  Is that correct?
>>>>
>>>> If so, I suspect its because we drive the tcp_hpts_softclock() routine 
>>>> from userret(), in order to avoid tons of timer interrupts and context 
>>>> switches.  To test this theory,  you could apply a patch like:
>>>
>>> It's affecting overall system performance, bonnie was just a way to
>>> get some numbers to compare.
>>>
>>> Tomorrow I will test patch.
>>>
>>> Thanks!
>>>
>>> --
>>> Nuno Teixeira
>>> FreeBSD Committer (ports)
>>
>>
>>
>> -- 
>> Nuno Teixeira
>> FreeBSD Committer (ports)



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
> freebsd   freebsd  0
> rack* rack 38
> ---
> 
> 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 Netflix
and allows to mitigate the performance regression.

Best regards
Michael
> 
> Thanks all!
> Really happy here :)
> 
> Cheers,
> 
> Nuno Teixeira  escreveu (domingo, 17/03/2024 à(s) 20:26):
>> 
>> Hello,
>> 
>>> I don't have the full context, but it seems like the complaint is a 
>>> performance regression in bonnie++ and perhaps other things when tcp_hpts 
>>> is loaded, even when it is not used.  Is that correct?
>>> 
>>> If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
>>> userret(), in order to avoid tons of timer interrupts and context switches. 
>>>  To test this theory,  you could apply a patch like:
>> 
>> It's affecting overall system performance, bonnie was just a way to
>> get some numbers to compare.
>> 
>> Tomorrow I will test patch.
>> 
>> Thanks!
>> 
>> --
>> Nuno Teixeira
>> FreeBSD Committer (ports)
> 
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)




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* rack 38
---

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 all!
Really happy here :)

Cheers,

Nuno Teixeira  escreveu (domingo, 17/03/2024 à(s) 20:26):
>
> Hello,
>
> > I don't have the full context, but it seems like the complaint is a 
> > performance regression in bonnie++ and perhaps other things when tcp_hpts 
> > is loaded, even when it is not used.  Is that correct?
> >
> > If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
> > userret(), in order to avoid tons of timer interrupts and context switches. 
> >  To test this theory,  you could apply a patch like:
>
> It's affecting overall system performance, bonnie was just a way to
> get some numbers to compare.
>
> Tomorrow I will test patch.
>
> Thanks!
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)



-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-17 Thread Nuno Teixeira
Hello,

> I don't have the full context, but it seems like the complaint is a 
> performance regression in bonnie++ and perhaps other things when tcp_hpts is 
> loaded, even when it is not used.  Is that correct?
>
> If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
> userret(), in order to avoid tons of timer interrupts and context switches.  
> To test this theory,  you could apply a patch like:

It's affecting overall system performance, bonnie was just a way to
get some numbers to compare.

Tomorrow I will test patch.

Thanks!

-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-17 Thread tuexen
> On 17. Mar 2024, at 16:39, Drew Gallatin  wrote:
> 
> I don't have the full context, but it seems like the complaint is a 
> performance regression in bonnie++ and perhaps other things when tcp_hpts is 
> loaded, even when it is not used.  Is that correct?
Correct.
> 
> If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
> userret(), in order to avoid tons of timer interrupts and context switches.  
> To test this theory,  you could apply a patch like:
> 
> diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c
> index e9a16cd0b36e..54b540c97123 100644
> --- a/sys/kern/subr_trap.c
> +++ b/sys/kern/subr_trap.c
> @@ -138,7 +138,7 @@ userret(struct thread *td, struct trapframe *frame)
> * Software Timer Support for Network Processing"
> * by Mohit Aron and Peter Druschel.
> */
> -   tcp_hpts_softclock();
> +   /*tcp_hpts_softclock();*/
>/*
> * Let the scheduler adjust our priority etc.
> */
> 
> 
> If that fixes it, I suspect we should either make this hook optional for 
> casual users of tcp_hpts(), or add some kind of "last called" timestamp to 
> prevent it being called over and over and over on workloads which are syscall 
> heavy.
Nuno, can you test that?
> 
> Note that for non-casual users of hpts (like Netflix, with hundreds of 
> thousands of TCP connections managed by hpts), this call is a huge win, so I 
> think we'd prefer that it remain in some form.
Sure.

Best regards
Michael
> 
> Drew





Re: Request for Testing: TCP RACK

2024-03-17 Thread Tomoaki AOKI
On Sun, 17 Mar 2024 11:40:54 -0400
"Drew Gallatin"  wrote:

> Resending with the patch as an attachment.
> 
> Drew
> 
> On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote:
> > I don't have the full context, but it seems like the complaint is a 
> > performance regression in bonnie++ and perhaps other things when tcp_hpts 
> > is loaded, even when it is not used.  Is that correct?
> > 
> > If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
> > userret(), in order to avoid tons of timer interrupts and context switches. 
> >  To test this theory,  you could apply a patch like:
> > 
> > diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c
> > index e9a16cd0b36e..54b540c97123 100644
> > --- a/sys/kern/subr_trap.c
> > +++ b/sys/kern/subr_trap.c
> > @@ -138,7 +138,7 @@ userret(struct thread *td, struct trapframe *frame)
> >  * Software Timer Support for Network Processing"
> >  * by Mohit Aron and Peter Druschel.
> >  */
> > -   tcp_hpts_softclock();
> > +   /*tcp_hpts_softclock();*/
> > /*
> >  * Let the scheduler adjust our priority etc.
> >  */
> > 
> > 
> > If that fixes it, I suspect we should either make this hook optional for 
> > casual users of tcp_hpts(), or add some kind of "last called" timestamp to 
> > prevent it being called over and over and over on workloads which are 
> > syscall heavy.
> > 
> > Note that for non-casual users of hpts (like Netflix, with hundreds of 
> > thousands of TCP connections managed by hpts), this call is a huge win, so 
> > I think we'd prefer that it remain in some form.
> > 
> > Drew

Controlled via RW or RWTUN sysctl/tunable?

-- 
Tomoaki AOKI



Re: Request for Testing: TCP RACK

2024-03-17 Thread Drew Gallatin
Resending with the patch as an attachment.

Drew

On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote:
> I don't have the full context, but it seems like the complaint is a 
> performance regression in bonnie++ and perhaps other things when tcp_hpts is 
> loaded, even when it is not used.  Is that correct?
> 
> If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
> userret(), in order to avoid tons of timer interrupts and context switches.  
> To test this theory,  you could apply a patch like:
> 
> diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c
> index e9a16cd0b36e..54b540c97123 100644
> --- a/sys/kern/subr_trap.c
> +++ b/sys/kern/subr_trap.c
> @@ -138,7 +138,7 @@ userret(struct thread *td, struct trapframe *frame)
>  * Software Timer Support for Network Processing"
>  * by Mohit Aron and Peter Druschel.
>  */
> -   tcp_hpts_softclock();
> +   /*tcp_hpts_softclock();*/
> /*
>  * Let the scheduler adjust our priority etc.
>  */
> 
> 
> If that fixes it, I suspect we should either make this hook optional for 
> casual users of tcp_hpts(), or add some kind of "last called" timestamp to 
> prevent it being called over and over and over on workloads which are syscall 
> heavy.
> 
> Note that for non-casual users of hpts (like Netflix, with hundreds of 
> thousands of TCP connections managed by hpts), this call is a huge win, so I 
> think we'd prefer that it remain in some form.
> 
> Drew
> 

nerf_tcp_hpts_softclock.diff
Description: Binary data


Re: Request for Testing: TCP RACK

2024-03-17 Thread Drew Gallatin
I don't have the full context, but it seems like the complaint is a performance 
regression in bonnie++ and perhaps other things when tcp_hpts is loaded, even 
when it is not used.  Is that correct?

If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
userret(), in order to avoid tons of timer interrupts and context switches.  To 
test this theory,  you could apply a patch like:

diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c
index e9a16cd0b36e..54b540c97123 100644
--- a/sys/kern/subr_trap.c
+++ b/sys/kern/subr_trap.c
@@ -138,7 +138,7 @@ userret(struct thread *td, struct trapframe *frame)
 * Software Timer Support for Network Processing"
 * by Mohit Aron and Peter Druschel.
 */
-   tcp_hpts_softclock();
+   /*tcp_hpts_softclock();*/
/*
 * Let the scheduler adjust our priority etc.
 */


If that fixes it, I suspect we should either make this hook optional for casual 
users of tcp_hpts(), or add some kind of "last called" timestamp to prevent it 
being called over and over and over on workloads which are syscall heavy.

Note that for non-casual users of hpts (like Netflix, with hundreds of 
thousands of TCP connections managed by hpts), this call is a huge win, so I 
think we'd prefer that it remain in some form.

Drew


Re: Request for Testing: TCP RACK

2024-03-17 Thread Nuno Teixeira
Hello,

> > - I can't remember better tests to do as I can feel the entire OS is
> > being slow, without errors, just slow.
> This is interesting. It seems a consequence on loading TCPHPTS, not actually
> using it.

Exactly, just loading module and not using it by setting sysctl.

> I have CCed Drew and Randall, who know much more about HPTS and might have
> follow up questions. I'll bring the issue up in the FreeBSD transport call
> next Thursday.
>
> What hardware are you using?

Laptop:
Legion 5-15IMH05 (Lenovo) - Type 82AU

Thanks!

-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-17 Thread tuexen
> On 16. Mar 2024, at 21:29, Nuno Teixeira  wrote:
> 
>> Just to double check: you only load the tcp_rack. You don't run
>> sysctl net.inet.tcp.functions_default=rack
> 
> I'm not using sysctl, just loading module.
And you also don't have
net.inet.tcp.functions_default=rack
in /etc/sysctl.conf
This means that no TCP connection will actually use the RACK stack.
> 
>> What does "poudriere testport net/gitup" do? Only build stuff or does is
>> also download something?
>> 
>> What does bonnie++ do?
> 
> poudriere is for testing ports and it uses jails to build stuff.
> It have restrict access to net to fetch distfiles (not the case as
> distfile is present on disk)
> 
> bonnie++ is a disk benchmark
Thanks for clarifying.
> 
>> Could you reboot the system, run the test, do kldload tcphpts, run
>> the test again, do kldload tcp_rack, and run it again.
> 
> The previous test [2] was obtained by loading tcp_rack
> 
> Now I will post results for test [3] by loading (only) tcphpts module.
Great. This makes sure that the degradation is related to TCPHPTS and
not the RACK stack.
> 
> [3] kldload tcphpts:
> 
> ==> poudriere testport net/gitup:
> 55.26s real 5.23s user  1m19.91s sys
So this test goes up from 11 seconds to 55 seconds...
> 
> ==> bonnie++
> Version  1.98   --Sequential Output-- --Sequential Input- 
> --Random-
>   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
> %CP
> leg.home32G   12k  99 73.0m  99 51.1m  99   27k  99  128m  99  8038 
> 2194
> Latency  1763ms 194ms   23979us 431ms1267us2776us
> Version  1.98   --Sequential Create-- Random 
> Create
> leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
> files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>16 7017.934752  98 21243.823180 100 7780.918458  99
> 9281.48  98 21368.647657 100 7457.828733  99
> Latency  3015us 220us2398us1106us 386us2473us
> 
> Summary:
> 
> - I can't remember better tests to do as I can feel the entire OS is
> being slow, without errors, just slow.
This is interesting. It seems a consequence on loading TCPHPTS, not actually
using it.

I have CCed Drew and Randall, who know much more about HPTS and might have
follow up questions. I'll bring the issue up in the FreeBSD transport call
next Thursday.

What hardware are you using?

Best regards
Michael
> - Approx. results as test [2]
> 
> 
> 
> 
> Nuno Teixeira
> FreeBSD Committer (ports)




Re: Request for Testing: TCP RACK

2024-03-16 Thread Tomoaki AOKI
On Sun, 19 Nov 2023 04:01:01 +0900
Tomoaki AOKI  wrote:

> On Sat, 18 Nov 2023 09:50:43 +0100
> tue...@freebsd.org wrote:
> 
> > > On Nov 18, 2023, at 00:37, Tomoaki AOKI  wrote:
> > > 
> > > On Fri, 17 Nov 2023 18:51:05 +0100
> > > tue...@freebsd.org wrote:
> > > 
> > >>> On Nov 17, 2023, at 17:06, Johan Hendriks  
> > >>> wrote:
> > >>> 
> > >>> I am running the rack stack for quiet some time now on a baremetal 
> > >>> machiene and never had problems.
> > >>> Also use pf.  This is a test machine so not a lot happening on it.
> > >>> 
> > >>> Are there any thing we can test? Do we have some test scripts we can 
> > >>> run?
> > >> We are actually interested in feedback about using the stack in whatever
> > >> use case you use TCP for. The stack has been tested with the Netflix use
> > >> case, but not so much with others. That is why we ask for broader 
> > >> testing.
> > >> 
> > >> Best regards
> > >> Michael
> > > 
> > > Are there any difference regarding with performance between main and
> > > stable/14? If so, please ignore below.
> > > 
> > > I have stable/14 environment which is configured to be able to switch
> > > to TCP RACK and experienced huge performance loss when writing
> > > a large file to smbfs share on commercial NAS. CC is cubic.
> > > Testing large archive on the smbfs share doesn't seem to be
> > > affected.
> > > 
> > > Comparison between default (freebsd) and rack TCP stack using
> > > sysutils/clone on stable/14 at commit 7d1321288ad9, amd64.
> > > Last 3 lines of outputs from clone (upload to NAS) are shown.
> > Thank you very much for testing. This is what we are looking
> > for. Would it be possible to repeat the test using NewReno as
> > the CC?
> > 
> > Best regards
> > Michael
> 
> Sure. Here we go!
> 
> sysctl net.inet.tcp.functions_default
> net.inet.tcp.functions_default: freebsd
> sysctl net.inet.tcp.cc.algorithm 
> net.inet.tcp.cc.algorithm: newreno
> Umounted and remounted smbfs share.
> 
> 1 item copied, 2343.1 MB in 37.65 s -- 62.2 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> 
> sysctl net.inet.tcp.functions_default
> net.inet.tcp.functions_default: rack
> Umounted and remounted smbfs share.
> 
> 1 item copied, 2343.1 MB in 905.17 s -- 2.6 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> 
> sysctl net.inet.tcp.functions_default
> net.inet.tcp.functions_default: freebsd
> Without umount and remount to reproduce previous oddness, maybe caused
> by keep-alive.
> 
> 1 item copied, 2343.1 MB in 897.67 s -- 2.6 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> 
> Umounted and remounted, without change for CC and TCP stack.
> 
> 1 item copied, 2343.1 MB in 37.43 s -- 62.6 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> 
> All test are proceeded simultaneously. So the last one is with
> CC=newreno and TCP stack=freebsd.
> 
> Not exactly recorded, but testing transferred file by
> diff -u -p -N was roughly 30MB/sec, while roughly 25MB/sec with
> CC=cubic.
> 
> 
> > > 
> > > Before switching to rack:
> > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> > > Leaked memory: 0 bytes
> > > No errors occured.
> > > 
> > > Unmount the smbfs share, switch to rack, and after remount:
> > > 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s
> > > Leaked memory: 0 bytes
> > > No errors occured.
> > > 
> > > Switch back to freebsd (default) without unmounting:
> > > 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s
> > > Leaked memory: 0 bytes
> > > No errors occured.
> > > 
> > > Unmount and remount the smbfs share:
> > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> > > Leaked memory: 0 bytes
> > > No errors occured.
> > > 
> > > 
> > > Regards.
> > > 
> > > -- 
> > > Tomoaki AOKI
> 
> 
> -- 
> Tomoaki AOKI

Just a follow up.

This situation does not changed on stable/14, amd64 until commit
a15b8e32942b2cbf70c7fc71e9c82d2b292e82c3. (So I've never reported again
until now. Not tested on every updates.)

tcphpts.ko is loaded.

Note that options RATELIMIT and options TCPHPTS are dropped when
changes to RACK is MFC'ed and added tcphpts_load="YES"
in /boot/loader.conf instaad.

Another note:
Differences between CC=newreno and CC=cubic on testing transferred file
seems to be just a fudge factor. both vaies mostly between the two
values which I've previously reported.


-- 
Tomoaki AOKI



Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
> Just to double check: you only load the tcp_rack. You don't run
> sysctl net.inet.tcp.functions_default=rack

I'm not using sysctl, just loading module.

> What does "poudriere testport net/gitup" do? Only build stuff or does is
> also download something?
>
> What does bonnie++ do?

poudriere is for testing ports and it uses jails to build stuff.
It have restrict access to net to fetch distfiles (not the case as
distfile is present on disk)

bonnie++ is a disk benchmark

> Could you reboot the system, run the test, do kldload tcphpts, run
> the test again, do kldload tcp_rack, and run it again.

The previous test [2] was obtained by loading tcp_rack

Now I will post results for test [3] by loading (only) tcphpts module.

[3] kldload tcphpts:

==> poudriere testport net/gitup:
55.26s real 5.23s user  1m19.91s sys

==> bonnie++
Version  1.98   --Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
leg.home32G   12k  99 73.0m  99 51.1m  99   27k  99  128m  99  8038 2194
Latency  1763ms 194ms   23979us 431ms1267us2776us
Version  1.98   --Sequential Create-- Random Create
leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
 16 7017.934752  98 21243.823180 100 7780.918458  99
9281.48  98 21368.647657 100 7457.828733  99
Latency  3015us 220us2398us1106us 386us2473us

Summary:

- I can't remember better tests to do as I can feel the entire OS is
being slow, without errors, just slow.
- Approx. results as test [2]




Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-16 Thread tuexen
> On 16. Mar 2024, at 20:06, Nuno Teixeira  wrote:
> 
>>> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
>> Please do so...
> 
> @main-n268827-75464941dc17 GENERIC-NODEBUG amd64
> 
> Ok, I think I have here some numbers related to disk performance being
> affected by tcp_rack that somehow is messing with something.
> 
> NOTES:
> - test [1] was done after a boot without tcp_rack in loader.conf and
> [2] tcp_rack was loaded manually with kldload (without rebooting)
> - After unloading tcp_rack, same results as [2]
> - Cannot unload tcptpts: device busy
tcphpts does not support unloading. So that is fine.

Just to double check: you only load the tcp_rack. You don't run
sysctl net.inet.tcp.functions_default=rack

This means you load RACK, but you don't use it.

What does "poudriere testport net/gitup" do? Only build stuff or does is
also download something?

What does bonnie++ do?

Could you reboot the system, run the test, do kldload tcphpts, run
the test again, do kldload tcp_rack, and run it again.

I'm wondering if tcphpts is affecting the measurements...

Thanks for testing.

Best regards
Michael
> 
> [1] without tcp_rack loaded:
> 
> ==> poudriere testport net/gitup:
> 11.16s real 5.35s user  6.35s sys
> 
> ==> bonnie++:
> Version  1.98   --Sequential Output-- --Sequential Input- 
> --Random-
>   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
> %CP
> leg.home32G   25k  99  105m  99 88.7m  99   77k  99  198m  99 12716 
> 1784
> Latency   351ms1793us2340us 241ms 638us2514us
> Version  1.98   --Sequential Create-- Random 
> Create
> leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
> files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>16 14908.273230  97 + +++ 6878.516657  99
> 15194.808063  97 + +++ 8019.731670  99
> Latency  1108us 182us2228us1013us 152us2424us
> 
> [2] kldload tcp_rack:
> 
> ==> poudriere testport net/gitup:
> 1m0.54s real4.98s user  1m31.38s sys
> 
> ==> bonnie++:
> Version  1.98   --Sequential Output-- --Sequential Input- 
> --Random-
>   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
> %CP
> leg.home32G   14k  99 78.0m  99 46.6m  99   25k  99  120m  99  6688 
> 2161
> Latency   676ms   18309us   76171us 385ms 924us2274us
> Version  1.98   --Sequential Create-- Random 
> Create
> leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
> files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>16 8139.513260  96 19437.792294  99 5494.638508  99
> 8099.275425  96 19723.528878  99 6363.123671  99
> Latency  2982us 338us3072us1135us 591us3236us
> 
> Cheers,
> 
> 
> 
> 
> 
> 
> 
> --
> Nuno Teixeira
> FreeBSD Committer (ports)




Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
> > Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
> Please do so...

@main-n268827-75464941dc17 GENERIC-NODEBUG amd64

Ok, I think I have here some numbers related to disk performance being
affected by tcp_rack that somehow is messing with something.

NOTES:
- test [1] was done after a boot without tcp_rack in loader.conf and
[2] tcp_rack was loaded manually with kldload (without rebooting)
- After unloading tcp_rack, same results as [2]
- Cannot unload tcptpts: device busy

[1] without tcp_rack loaded:

==> poudriere testport net/gitup:
11.16s real 5.35s user  6.35s sys

==> bonnie++:
Version  1.98   --Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
leg.home32G   25k  99  105m  99 88.7m  99   77k  99  198m  99 12716 1784
Latency   351ms1793us2340us 241ms 638us2514us
Version  1.98   --Sequential Create-- Random Create
leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
 16 14908.273230  97 + +++ 6878.516657  99
15194.808063  97 + +++ 8019.731670  99
Latency  1108us 182us2228us1013us 152us2424us

[2] kldload tcp_rack:

==> poudriere testport net/gitup:
1m0.54s real4.98s user  1m31.38s sys

==> bonnie++:
Version  1.98   --Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
leg.home32G   14k  99 78.0m  99 46.6m  99   25k  99  120m  99  6688 2161
Latency   676ms   18309us   76171us 385ms 924us2274us
Version  1.98   --Sequential Create-- Random Create
leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
 16 8139.513260  96 19437.792294  99 5494.638508  99
8099.275425  96 19723.528878  99 6363.123671  99
Latency  2982us 338us3072us1135us 591us3236us

Cheers,







--
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-16 Thread tuexen
> On 16. Mar 2024, at 15:00, Nuno Teixeira  wrote:
> 
>> If you load tcp_rack via kldload, tcphtps get loaded automatically.
>> If you load if via /boot/loader.conf, you need to have
>> tcphpts_load="YES"
>> in addition to
>> tcp_rack_load="YES"
> 
> As of my tests, loader.conf: tcp_rack_load="YES" loads tcphtps.ko auto:
> 
> 31 0x81f53000545e0 tcp_rack.ko
> 42 0x81fa800014588 tcphpts.ko
Interesting. Works on my arm64 machine, too. I think when I tested things
for writing the article, I figured out that just doing
tcp_rack_load="YES"
in /boot/loader.conf was not working on a kernel configured without
TCPHPTS.
> 
> On aarch64 (rpi4) I didn't get any performance issues in
> 
> main-n268730-96ad640178ea (Mar 8)
> and
> main-n268827-75464941dc17 (Mar 16)
> 
> So it seems not related to rack commit e18b97bd63a8: Update to bring
> the rack stack with all its fixes in.
> 
> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
Please do so...

Best regards
Michael
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)




Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
> If you load tcp_rack via kldload, tcphtps get loaded automatically.
> If you load if via /boot/loader.conf, you need to have
> tcphpts_load="YES"
> in addition to
> tcp_rack_load="YES"

As of my tests, loader.conf: tcp_rack_load="YES" loads tcphtps.ko auto:

31 0x81f53000545e0 tcp_rack.ko
42 0x81fa800014588 tcphpts.ko

On aarch64 (rpi4) I didn't get any performance issues in

main-n268730-96ad640178ea (Mar 8)
and
main-n268827-75464941dc17 (Mar 16)

So it seems not related to rack commit e18b97bd63a8: Update to bring
the rack stack with all its fixes in.

Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-16 Thread tuexen
> On 16. Mar 2024, at 11:59, Nuno Teixeira  wrote:
> 
>>> Resuming I only need to add:
>>> 
>>> options TCPHPTS
>>> 
>>> Is this correct?
>>> 
>> 
>> Yeah, that will probably fix it.  According to a comment in
>> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
>> system for tcp, used by RACK and BBR.
> 
> As tuexen said, on main, loader.conf: tcp_rack_load="YES" will load
> tcphpts.ko as I am seing in my rpi4 right now.
If you load tcp_rack via kldload, tcphtps get loaded automatically.
If you load if via /boot/loader.conf, you need to have
tcphpts_load="YES"
in addition to
tcp_rack_load="YES"

Best regards
Michael
> I'm testing it and check its performance.
> 
> I will test again on my amd64 laptop and run more tests too.
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)




Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
> > Resuming I only need to add:
> >
> > options TCPHPTS
> >
> > Is this correct?
> >
>
> Yeah, that will probably fix it.  According to a comment in
> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
> system for tcp, used by RACK and BBR.

As tuexen said, on main, loader.conf: tcp_rack_load="YES" will load
tcphpts.ko as I am seing in my rpi4 right now.
I'm testing it and check its performance.

I will test again on my amd64 laptop and run more tests too.


-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-16 Thread Gary Jennejohn
On Sat, 16 Mar 2024 10:11:22 +
Nuno Teixeira  wrote:

> (...)
>
> > These entries are missing in GENERIC:
> >
> > makeoptions WITH_EXTRA_TCP_STACKS=1
>
> From 
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was  dropped.
>
> > options TCPHPTS
>
> That's the missing option in GENERIC that could lead to my slow
> opearations problem
>
> > options TCP_RACK
>
> Don't think I need this one as I will use kernel module instead of
> building it in kernel.
>
> Resuming I only need to add:
>
> options TCPHPTS
>
> Is this correct?
>

Yeah, that will probably fix it.  According to a comment in
/usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
system for tcp, used by RACK and BBR.

--
Gary Jennejohn



Re: Request for Testing: TCP RACK

2024-03-16 Thread tuexen
> On 16. Mar 2024, at 11:11, Nuno Teixeira  wrote:
> 
> (...)
> 
>> These entries are missing in GENERIC:
>> 
>> makeoptions WITH_EXTRA_TCP_STACKS=1
> 
> From 
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was  dropped.
> 
>> options TCPHPTS
> 
> That's the missing option in GENERIC that could lead to my slow
> opearations problem
On main, this will be automatically loaded as a module when you
load tcp_rack.
> 
>> options TCP_RACK
> 
> Don't think I need this one as I will use kernel module instead of
> building it in kernel.
Correct.
> 
> Resuming I only need to add:
> 
> options TCPHPTS
> 
> Is this correct?
No. Not on main.

Best regards
Michael
> 
> Thanks,
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)




Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
(...)

> These entries are missing in GENERIC:
>
> makeoptions WITH_EXTRA_TCP_STACKS=1

>From 
>https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
WITH_EXTRA_TCP_STACKS was  dropped.

> options TCPHPTS

That's the missing option in GENERIC that could lead to my slow
opearations problem

> options TCP_RACK

Don't think I need this one as I will use kernel module instead of
building it in kernel.

Resuming I only need to add:

options TCPHPTS

Is this correct?

Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-16 Thread Gary Jennejohn
On Sat, 16 Mar 2024 09:49:24 +
Nuno Teixeira  wrote:

> Hello Gary,
>
> Nice that you found this.
>
> tcp_tack manual doesn't mention that we need extra config in kernel
> but it loads module and it is shown in sysctl
> net.inet.tcp.functions_available without errors.
>
> I will add missing config to GENERIC and see how it goes.
>

All the required information is here:

https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/

--
Gary Jennejohn



Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
Hello Gary,

Nice that you found this.

tcp_tack manual doesn't mention that we need extra config in kernel
but it loads module and it is shown in sysctl
net.inet.tcp.functions_available without errors.

I will add missing config to GENERIC and see how it goes.

Cheers,


Gary Jennejohn  escreveu (sábado, 16/03/2024 à(s) 09:40):
>
> On Sat, 16 Mar 2024 09:41:13 +0100
> tue...@freebsd.org wrote:
>
> > > On 16. Mar 2024, at 08:57, Nuno Teixeira  wrote:
> > >
> > > Hello all,
> > >
> > > On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> > > noticed that all operations on OS was increased by 3 to 5 times
> > > longer.
> > > examples:
> > > - firefox took way long time to open
> > > - poudriere testport tooked up to 3 times longer to finished
> >
> > make.conf:
> > KERNCONF=GENERIC-NODEBUG
> > src.conf:
> > WITH_MALLOC_PRODUCTION=yes
> >
> > tested on main-n268800-6a6ec90681cf
> >
>
> > How did you enable the RACK stack? Does the poudriere involve
> > network interaction?
> >
>
> Interesting.  RACK works for me:
>
> net.inet.tcp.functions_available:
> Stack   D AliasPCB count
> freebsd   freebsd  0
> rack* rack 23
>
> I don't see any lags when starting/using FireFox or any other browser.
>
> Mail delivery (in/out) is also not affected.
>
> But GENERIC, which is loaded by GENERIC-NODEBUG, doesn't support RACK.
>
> These entries are missing in GENERIC:
>
> makeoptions WITH_EXTRA_TCP_STACKS=1
> options TCPHPTS
> options TCP_RACK
>
> --
> Gary Jennejohn



-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
Followed man tcp_rack:

loader.conf:
tcp_rack_load="YES"
sysctl.conf:
net.inet.tcp.functions_default=rack

poudriere have restricted access to network, usually for fetch distfiles.

 escreveu (sábado, 16/03/2024 à(s) 08:41):
>
> > On 16. Mar 2024, at 08:57, Nuno Teixeira  wrote:
> >
> > Hello all,
> >
> > On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> > noticed that all operations on OS was increased by 3 to 5 times
> > longer.
> > examples:
> > - firefox took way long time to open
> > - poudriere testport tooked up to 3 times longer to finished
> How did you enable the RACK stack? Does the poudriere involve
> network interaction?
>
> Best regards
> Michael
> >
> > make.conf:
> > KERNCONF=GENERIC-NODEBUG
> > src.conf:
> > WITH_MALLOC_PRODUCTION=yes
> >
> > tested on main-n268800-6a6ec90681cf
> >
> > Thanks,
> >
> >  escreveu (quinta, 14/03/2024 à(s) 10:51):
> >>
> >>> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav  wrote:
> >>>
> >>> tue...@freebsd.org writes:
> >>>> Gary Jennejohn  writes:
> >>>>> In the article we have option TCPHPTS and option TCP_RACK.  But in
> >>>>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
> >>>>> not option.
> >>>> Thanks for reporting, that is a typo in the article. It should
> >>>> always read options instead of option.
> >>>
> >>> It's not a typo, both spellings work, cf. config(5).
> >> Thank you very much for the hint. I did not know this. I wrote
> >> option in the article (for whatever reason) and tested the
> >> configs using options...
> >>
> >> Best regards
> >> Michael
> >>>
> >>> DES
> >>> --
> >>> Dag-Erling Smørgrav - d...@freebsd.org
> >>
> >
> >
> > --
> > Nuno Teixeira
> > FreeBSD Committer (ports)
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-16 Thread Gary Jennejohn
On Sat, 16 Mar 2024 09:41:13 +0100
tue...@freebsd.org wrote:

> > On 16. Mar 2024, at 08:57, Nuno Teixeira  wrote:
> >
> > Hello all,
> >
> > On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> > noticed that all operations on OS was increased by 3 to 5 times
> > longer.
> > examples:
> > - firefox took way long time to open
> > - poudriere testport tooked up to 3 times longer to finished
>
> make.conf:
> KERNCONF=GENERIC-NODEBUG
> src.conf:
> WITH_MALLOC_PRODUCTION=yes
>
> tested on main-n268800-6a6ec90681cf
>

> How did you enable the RACK stack? Does the poudriere involve
> network interaction?
>

Interesting.  RACK works for me:

net.inet.tcp.functions_available:
Stack   D AliasPCB count
freebsd   freebsd  0
rack* rack 23

I don't see any lags when starting/using FireFox or any other browser.

Mail delivery (in/out) is also not affected.

But GENERIC, which is loaded by GENERIC-NODEBUG, doesn't support RACK.

These entries are missing in GENERIC:

makeoptions WITH_EXTRA_TCP_STACKS=1
options TCPHPTS
options TCP_RACK

--
Gary Jennejohn



Re: Request for Testing: TCP RACK

2024-03-16 Thread tuexen
> On 16. Mar 2024, at 08:57, Nuno Teixeira  wrote:
> 
> Hello all,
> 
> On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> noticed that all operations on OS was increased by 3 to 5 times
> longer.
> examples:
> - firefox took way long time to open
> - poudriere testport tooked up to 3 times longer to finished
How did you enable the RACK stack? Does the poudriere involve
network interaction?

Best regards
Michael
> 
> make.conf:
> KERNCONF=GENERIC-NODEBUG
> src.conf:
> WITH_MALLOC_PRODUCTION=yes
> 
> tested on main-n268800-6a6ec90681cf
> 
> Thanks,
> 
>  escreveu (quinta, 14/03/2024 à(s) 10:51):
>> 
>>> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav  wrote:
>>> 
>>> tue...@freebsd.org writes:
>>>> Gary Jennejohn  writes:
>>>>> In the article we have option TCPHPTS and option TCP_RACK.  But in
>>>>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
>>>>> not option.
>>>> Thanks for reporting, that is a typo in the article. It should
>>>> always read options instead of option.
>>> 
>>> It's not a typo, both spellings work, cf. config(5).
>> Thank you very much for the hint. I did not know this. I wrote
>> option in the article (for whatever reason) and tested the
>> configs using options...
>> 
>> Best regards
>> Michael
>>> 
>>> DES
>>> --
>>> Dag-Erling Smørgrav - d...@freebsd.org
>> 
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)




Re: Request for Testing: TCP RACK

2024-03-16 Thread Nuno Teixeira
Hello all,

On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
noticed that all operations on OS was increased by 3 to 5 times
longer.
examples:
- firefox took way long time to open
- poudriere testport tooked up to 3 times longer to finished

make.conf:
KERNCONF=GENERIC-NODEBUG
src.conf:
WITH_MALLOC_PRODUCTION=yes

tested on main-n268800-6a6ec90681cf

Thanks,

 escreveu (quinta, 14/03/2024 à(s) 10:51):
>
> > On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav  wrote:
> >
> > tue...@freebsd.org writes:
> >> Gary Jennejohn  writes:
> >>> In the article we have option TCPHPTS and option TCP_RACK.  But in
> >>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
> >>> not option.
> >> Thanks for reporting, that is a typo in the article. It should
> >> always read options instead of option.
> >
> > It's not a typo, both spellings work, cf. config(5).
> Thank you very much for the hint. I did not know this. I wrote
> option in the article (for whatever reason) and tested the
> configs using options...
>
> Best regards
> Michael
> >
> > DES
> > --
> > Dag-Erling Smørgrav - d...@freebsd.org
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-03-14 Thread tuexen
> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav  wrote:
> 
> tue...@freebsd.org writes:
>> Gary Jennejohn  writes:
>>> In the article we have option TCPHPTS and option TCP_RACK.  But in
>>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
>>> not option.
>> Thanks for reporting, that is a typo in the article. It should
>> always read options instead of option.
> 
> It's not a typo, both spellings work, cf. config(5).
Thank you very much for the hint. I did not know this. I wrote
option in the article (for whatever reason) and tested the
configs using options...

Best regards
Michael
> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@freebsd.org




Re: Request for Testing: TCP RACK

2024-03-14 Thread Dag-Erling Smørgrav
tue...@freebsd.org writes:
> Gary Jennejohn  writes:
> > In the article we have option TCPHPTS and option TCP_RACK.  But in
> > /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
> > not option.
> Thanks for reporting, that is a typo in the article. It should
> always read options instead of option.

It's not a typo, both spellings work, cf. config(5).

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org



Re: Request for Testing: TCP RACK

2024-03-13 Thread tuexen
> On 13. Mar 2024, at 08:06, Gary Jennejohn  wrote:
> 
> On Tue, 12 Mar 2024 20:14:17 +0100
> tue...@freebsd.org wrote:
> 
>>> On 12. Mar 2024, at 14:39, Nuno Teixeira  wrote:
>>> 
>>> Hello,
>>> 
>>> I'm curious about tcp RACK.
>>> 
>>> As I do not run on a server background, only a laptop and a rpi4 for
>>> poudriere, git, browsing, some torrent and ssh/sftp connections, will
>>> I see any difference using RACK?
>>> What tests should I do for comparison?
>> You might want to read the following article in the FreeBSD Journal:
>> https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/
>> 
>> There is no specific area for testing. Just test the stack on
>> the systems you use with the workload you use and report back
>> any issues...
>> 
> 
> In the article we have option TCPHPTS and option TCP_RACK.  But in
> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
> not option.
Thanks for reporting, that is a typo in the article. It should
always read options instead of option.

Best regards
Michael
> 
> --
> Gary Jennejohn




Re: Request for Testing: TCP RACK

2024-03-13 Thread Gary Jennejohn
On Tue, 12 Mar 2024 20:14:17 +0100
tue...@freebsd.org wrote:

> > On 12. Mar 2024, at 14:39, Nuno Teixeira  wrote:
> >
> > Hello,
> >
> > I'm curious about tcp RACK.
> >
> > As I do not run on a server background, only a laptop and a rpi4 for
> > poudriere, git, browsing, some torrent and ssh/sftp connections, will
> > I see any difference using RACK?
> > What tests should I do for comparison?
> You might want to read the following article in the FreeBSD Journal:
> https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/
>
> There is no specific area for testing. Just test the stack on
> the systems you use with the workload you use and report back
> any issues...
>

In the article we have option TCPHPTS and option TCP_RACK.  But in
/sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
not option.

--
Gary Jennejohn



Re: Request for Testing: TCP RACK

2024-03-12 Thread tuexen
> On 12. Mar 2024, at 14:39, Nuno Teixeira  wrote:
> 
> Hello,
> 
> I'm curious about tcp RACK.
> 
> As I do not run on a server background, only a laptop and a rpi4 for
> poudriere, git, browsing, some torrent and ssh/sftp connections, will
> I see any difference using RACK?
> What tests should I do for comparison?
You might want to read the following article in the FreeBSD Journal:
https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/

There is no specific area for testing. Just test the stack on
the systems you use with the workload you use and report back
any issues...

Best regards
Michael
> 
> Thanks,
> 
>  escreveu (quinta, 16/11/2023 à(s) 15:10):
>> 
>> 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
>> 
>> 
>> 
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)




Re: Request for Testing: TCP RACK

2024-03-12 Thread Pete Wright




On 3/12/24 6:39 AM, Nuno Teixeira wrote:

Hello,

I'm curious about tcp RACK.

As I do not run on a server background, only a laptop and a rpi4 for
poudriere, git, browsing, some torrent and ssh/sftp connections, will
I see any difference using RACK?
What tests should I do for comparison?



I found this blog post from Klara was a good backgrounder to get my 
comfortable with testing out RACK:

https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/

I've been using it on a busy'ish server and a workstation without any 
issues, but I'll defer to others as to what areas of focus for testing 
are needed.


-pete

--
Pete Wright
p...@nomadlogic.org



Re: Request for Testing: TCP RACK

2024-03-12 Thread Nuno Teixeira
Hello,

I'm curious about tcp RACK.

As I do not run on a server background, only a laptop and a rpi4 for
poudriere, git, browsing, some torrent and ssh/sftp connections, will
I see any difference using RACK?
What tests should I do for comparison?

Thanks,

 escreveu (quinta, 16/11/2023 à(s) 15:10):
>
> 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
>
>
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)



Re: Request for Testing: TCP RACK

2024-02-06 Thread Herbert J. Skuhra
On Tue, 06 Feb 2024 23:05:27 +0100, tue...@freebsd.org wrote:
> 
> > On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
> > 
> >> On Jan 4, 2024, at 21:39, Herbert J. Skuhra  wrote:
> >> 
> >> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
> >>> 
>  On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
>  
>  On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> > 
> > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >> 
> >> Hi,
> >> 
> >> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >>> 
>  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?
> >> 
> >> 1. It even fails with a simple pf.conf:
> >> pass in all
> >> pass out all
> >> 
> >> 2. Fetching port distfiles also failed.
> >> 
> >> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> > 
> > Disabling lro also resolves the issue.
>  
>  If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
>  disable rxcsum/tcxsum or lro on igb0.
> >>> Does the problem also goes away if you disable pf completely, but keep
> >>> compressed acks enabled?
> >> 
> >> Yes, it works with pf disabled and compressed acks enabled.
> > Thanks for the information!
> A patch is available at:
> https://reviews.freebsd.org/D43769

Hi Michael,

the patch resolves the issue.

Thanks a lot.

Best regards,
Herbert



Re: Request for Testing: TCP RACK

2024-02-06 Thread tuexen
> On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
> 
>> On Jan 4, 2024, at 21:39, Herbert J. Skuhra  wrote:
>> 
>> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>> 
 On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
 
 On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> 
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>> 
>> Hi,
>> 
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>> 
 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?
>> 
>> 1. It even fails with a simple pf.conf:
>> pass in all
>> pass out all
>> 
>> 2. Fetching port distfiles also failed.
>> 
>> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> 
> Disabling lro also resolves the issue.
 
 If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
 disable rxcsum/tcxsum or lro on igb0.
>>> Does the problem also goes away if you disable pf completely, but keep
>>> compressed acks enabled?
>> 
>> Yes, it works with pf disabled and compressed acks enabled.
> Thanks for the information!
A patch is available at:
https://reviews.freebsd.org/D43769

Best regards
Michael
> 
> Best regards
> Michael
>> 
>> --
>> Herbert
> 
> 




Re: Request for Testing: TCP RACK

2024-01-16 Thread Marek Zarychta

W dniu 17.11.2023 o 00:13, tue...@fh-muenster.de pisze:

On Nov 16, 2023, at 17:50, Marek Zarychta  wrote:

W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze:

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

That's really good news and long-awaited change. Thank you.

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.

Yes, please do it, at least for CURRENT. Last problem I have spotted with RACK 
was fixed in June: it was missing support TCP-MD5:
https://cgit.freebsd.org/src/commit/?id=02b885b09d1e90574162a1442b9ede06cef2b13a
We switched to RACK since upgrading to early stable/13 and genuinely appreciate 
this gift from Netflix. The performance improvement is invaluable, both in a 
lossy LAN and on a long-haul overseas TCP connection.

Please let me know if you have any questions.

Are any MFCs planned, especially to stable/14 ? Now, when stable/14 is almost 
in sync with main aka CURRENT it's an optimal time for such a MFC. When the 
change hits stable/14, it would be possible to test it extensively and have it 
fully functional in 14.1-RELEASE.

Let me bring that up on the next Transport call. Will report back.

Best regards
Michael


Thank you !

From now on stable/14 and in the future on 14.1-RELEASE one will be 
able to load tcp_rack and tcp_bbr out of the box running GENERIC kernel.[1]


1. https://cgit.freebsd.org/src/commit/?id=123fd2a




--
Marek Zarychta




Re: Request for Testing: TCP RACK

2024-01-04 Thread tuexen
> On Jan 4, 2024, at 21:39, Herbert J. Skuhra  wrote:
> 
> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>> 
>>> On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
>>> 
>>> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
 
 On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> 
> Hi,
> 
> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>> 
>>> 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?
> 
> 1. It even fails with a simple pf.conf:
> pass in all
> pass out all
> 
> 2. Fetching port distfiles also failed.
> 
> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
 
 Disabling lro also resolves the issue.
>>> 
>>> If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
>>> disable rxcsum/tcxsum or lro on igb0.
>> Does the problem also goes away if you disable pf completely, but keep
>> compressed acks enabled?
> 
> Yes, it works with pf disabled and compressed acks enabled.
Thanks for the information!

Best regards
Michael
> 
> --
> Herbert




Re: Request for Testing: TCP RACK

2024-01-04 Thread Herbert J. Skuhra
On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
> 
> > On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
> > 
> > On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> >> 
> >> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>  
> > 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?
> >>> 
> >>> 1. It even fails with a simple pf.conf:
> >>>  pass in all
> >>>  pass out all
> >>> 
> >>> 2. Fetching port distfiles also failed.
> >>> 
> >>> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> >> 
> >> Disabling lro also resolves the issue.
> > 
> > If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
> > disable rxcsum/tcxsum or lro on igb0.
> Does the problem also goes away if you disable pf completely, but keep
> compressed acks enabled?

Yes, it works with pf disabled and compressed acks enabled.

--
Herbert



Re: Request for Testing: TCP RACK

2024-01-04 Thread tuexen



> On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
> 
> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>> 
>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>> 
>>> Hi,
>>> 
>>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
 
> 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?
>>> 
>>> 1. It even fails with a simple pf.conf:
>>>  pass in all
>>>  pass out all
>>> 
>>> 2. Fetching port distfiles also failed.
>>> 
>>> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
>> 
>> Disabling lro also resolves the issue.
> 
> If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
> disable rxcsum/tcxsum or lro on igb0.
Does the problem also goes away if you disable pf completely, but keep
compressed acks enabled?

Best regards
Michael
> 
> --
> Herbert
> 




Re: Request for Testing: TCP RACK

2024-01-04 Thread Herbert J. Skuhra
On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> 
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> > 
> > Hi,
> > 
> > On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> > > 
> > > > 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?
> > 
> > 1. It even fails with a simple pf.conf:
> >pass in all
> >pass out all
> > 
> > 2. Fetching port distfiles also failed.
> > 
> > 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> 
> Disabling lro also resolves the issue.

If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
disable rxcsum/tcxsum or lro on igb0. 

--
Herbert



Re: Request for Testing: TCP RACK

2024-01-04 Thread tuexen
> On Jan 4, 2024, at 15:22, Herbert J. Skuhra  wrote:
> 
> On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>> 
>>> On Jan 4, 2024, at 11:40, Herbert J. Skuhra  wrote:
>>> 
>>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
 
 Hi,
 
 On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> 
>> 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?
 
 1. It even fails with a simple pf.conf:
 pass in all
 pass out all
 
 2. Fetching port distfiles also failed.
 
 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
>>> 
>>> Disabling lro also resolves the issue.
>>> 
>>> Not OK:
>>> 
>>> igb0: flags=1008843 metric 
>>> 0 mtu 1500
>>>  
>>> options=4e527bb
>>> 
>>> OK:
>>> 
>>> igb0: flags=1008843 metric 
>>> 0 mtu 1500
>>>  
>>> options=4e523bb
>> What kind of NIC do you have? Can you post the output of
>> dmesg | grep igb0
> 
> igb0:  port 0xf000-0xf01f mem 
> 0xfc20-0xfc27,0xfc28-0xfc283fff irq 28 at device 0.0 on pci3
> igb0: EEPROM V3.16-0 eTrack 0x84d6
> igb0: Using 1024 TX descriptors and 1024 RX descriptors
> igb0: Using 4 RX queues 4 TX queues
> igb0: Using MSI-X interrupts with 5 vectors
> igb0: Ethernet address: aa:bb:cc:dd:ee:ff
> igb0: netmap queues/slots: TX 4/1024, RX 4/1024
> igb0: link state changed to UP
> igb0: link state changed to DOWN
> igb0: link state changed to UP
Hi Herbert,

thank you very much. I'll see if I have such a NIC in one of my test systems 
and will report back.

Best regards
Michael
> 
> --
> Herbert
> 




Re: Request for Testing: TCP RACK

2024-01-04 Thread tuexen
> On Jan 4, 2024, at 11:40, Herbert J. Skuhra  wrote:
> 
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>> 
>> Hi,
>> 
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>> 
 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?
>> 
>> 1. It even fails with a simple pf.conf:
>> pass in all
>> pass out all
>> 
>> 2. Fetching port distfiles also failed.
>> 
>> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> 
> Disabling lro also resolves the issue.
> 
> Not OK:
> 
> igb0: flags=1008843 metric 0 
> mtu 1500
>  
> options=4e527bb
> 
> OK:
> 
> igb0: flags=1008843 metric 0 
> mtu 1500
>  
> options=4e523bb
What kind of NIC do you have? Can you post the output of
dmesg | grep igb0

Best regards
Michael
> 
> --
> Herbert
> 




Re: Request for Testing: TCP RACK

2024-01-04 Thread Herbert J. Skuhra
On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
> 
> > On Jan 4, 2024, at 11:40, Herbert J. Skuhra  wrote:
> > 
> > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >> 
> >> Hi,
> >> 
> >> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >>> 
>  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?
> >> 
> >> 1. It even fails with a simple pf.conf:
> >>   pass in all
> >>   pass out all
> >> 
> >> 2. Fetching port distfiles also failed.
> >> 
> >> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> > 
> > Disabling lro also resolves the issue.
> > 
> > Not OK:
> > 
> > igb0: flags=1008843 metric 
> > 0 mtu 1500
> >
> > options=4e527bb
> > 
> > OK:
> > 
> > igb0: flags=1008843 metric 
> > 0 mtu 1500
> >
> > options=4e523bb
> What kind of NIC do you have? Can you post the output of
> dmesg | grep igb0

igb0:  port 0xf000-0xf01f mem 
0xfc20-0xfc27,0xfc28-0xfc283fff irq 28 at device 0.0 on pci3
igb0: EEPROM V3.16-0 eTrack 0x84d6
igb0: Using 1024 TX descriptors and 1024 RX descriptors
igb0: Using 4 RX queues 4 TX queues
igb0: Using MSI-X interrupts with 5 vectors
igb0: Ethernet address: aa:bb:cc:dd:ee:ff
igb0: netmap queues/slots: TX 4/1024, RX 4/1024
igb0: link state changed to UP
igb0: link state changed to DOWN
igb0: link state changed to UP

--
Herbert



Re: Request for Testing: TCP RACK

2024-01-04 Thread Herbert J. Skuhra
On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> 
> Hi,
> 
> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> > 
> > > 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?
> 
> 1. It even fails with a simple pf.conf:
>pass in all
>pass out all
> 
> 2. Fetching port distfiles also failed.
> 
> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.

Disabling lro also resolves the issue.

Not OK:

igb0: flags=1008843 metric 0 
mtu 1500

options=4e527bb

OK:

igb0: flags=1008843 metric 0 
mtu 1500

options=4e523bb

--
Herbert



Re: Request for Testing: TCP RACK

2023-11-18 Thread Zhenlei Huang


> On Nov 19, 2023, at 2:35 AM, Zhenlei Huang  wrote:
> 
> 
> 
>> On Nov 16, 2023, at 5:13 PM, 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.
> 
> I see some performance regression with the rack stack.
> 
> This is iperf3 test on local host (bare metal, an old i5 2 cores 4 threads 
> MBP).
> 
> freebsd:  16.1 Gbits/sec
> rack: 12.3 Gbits/sec
> 
> The congestion control algorithm is cubic.
> 
> Note this is a quick test with DEBUG options enabled.
> 
> I'll try with no debug options and report later.

** UPDATE **

With no debug options:

freebsd:37.2 Gbits/sec
rack:   27.9 Gbits/sec

> 
>> 
>> 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
>> 
>> 
>> 
> 
> Best regards,
> Zhenlei





Re: Request for Testing: TCP RACK

2023-11-18 Thread Tomoaki AOKI
On Sat, 18 Nov 2023 09:50:43 +0100
tue...@freebsd.org wrote:

> > On Nov 18, 2023, at 00:37, Tomoaki AOKI  wrote:
> > 
> > On Fri, 17 Nov 2023 18:51:05 +0100
> > tue...@freebsd.org wrote:
> > 
> >>> On Nov 17, 2023, at 17:06, Johan Hendriks  wrote:
> >>> 
> >>> I am running the rack stack for quiet some time now on a baremetal 
> >>> machiene and never had problems.
> >>> Also use pf.  This is a test machine so not a lot happening on it.
> >>> 
> >>> Are there any thing we can test? Do we have some test scripts we can run?
> >> We are actually interested in feedback about using the stack in whatever
> >> use case you use TCP for. The stack has been tested with the Netflix use
> >> case, but not so much with others. That is why we ask for broader testing.
> >> 
> >> Best regards
> >> Michael
> > 
> > Are there any difference regarding with performance between main and
> > stable/14? If so, please ignore below.
> > 
> > I have stable/14 environment which is configured to be able to switch
> > to TCP RACK and experienced huge performance loss when writing
> > a large file to smbfs share on commercial NAS. CC is cubic.
> > Testing large archive on the smbfs share doesn't seem to be
> > affected.
> > 
> > Comparison between default (freebsd) and rack TCP stack using
> > sysutils/clone on stable/14 at commit 7d1321288ad9, amd64.
> > Last 3 lines of outputs from clone (upload to NAS) are shown.
> Thank you very much for testing. This is what we are looking
> for. Would it be possible to repeat the test using NewReno as
> the CC?
> 
> Best regards
> Michael

Sure. Here we go!

sysctl net.inet.tcp.functions_default
net.inet.tcp.functions_default: freebsd
sysctl net.inet.tcp.cc.algorithm 
net.inet.tcp.cc.algorithm: newreno
Umounted and remounted smbfs share.

1 item copied, 2343.1 MB in 37.65 s -- 62.2 MB/s
Leaked memory: 0 bytes
No errors occured.


sysctl net.inet.tcp.functions_default
net.inet.tcp.functions_default: rack
Umounted and remounted smbfs share.

1 item copied, 2343.1 MB in 905.17 s -- 2.6 MB/s
Leaked memory: 0 bytes
No errors occured.


sysctl net.inet.tcp.functions_default
net.inet.tcp.functions_default: freebsd
Without umount and remount to reproduce previous oddness, maybe caused
by keep-alive.

1 item copied, 2343.1 MB in 897.67 s -- 2.6 MB/s
Leaked memory: 0 bytes
No errors occured.


Umounted and remounted, without change for CC and TCP stack.

1 item copied, 2343.1 MB in 37.43 s -- 62.6 MB/s
Leaked memory: 0 bytes
No errors occured.


All test are proceeded simultaneously. So the last one is with
CC=newreno and TCP stack=freebsd.

Not exactly recorded, but testing transferred file by
diff -u -p -N was roughly 30MB/sec, while roughly 25MB/sec with
CC=cubic.


> > 
> > Before switching to rack:
> > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> > Leaked memory: 0 bytes
> > No errors occured.
> > 
> > Unmount the smbfs share, switch to rack, and after remount:
> > 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s
> > Leaked memory: 0 bytes
> > No errors occured.
> > 
> > Switch back to freebsd (default) without unmounting:
> > 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s
> > Leaked memory: 0 bytes
> > No errors occured.
> > 
> > Unmount and remount the smbfs share:
> > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> > Leaked memory: 0 bytes
> > No errors occured.
> > 
> > 
> > Regards.
> > 
> > -- 
> > Tomoaki AOKI


-- 
Tomoaki AOKI



Re: Request for Testing: TCP RACK

2023-11-18 Thread Zhenlei Huang



> On Nov 16, 2023, at 5:13 PM, 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.

I see some performance regression with the rack stack.

This is iperf3 test on local host (bare metal, an old i5 2 cores 4 threads MBP).

freebsd:16.1 Gbits/sec
rack:   12.3 Gbits/sec

The congestion control algorithm is cubic.

Note this is a quick test with DEBUG options enabled.

I'll try with no debug options and report later.

> 
> 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
> 
> 
> 

Best regards,
Zhenlei




Re: Request for Testing: TCP RACK

2023-11-18 Thread tuexen
> On Nov 18, 2023, at 00:37, Tomoaki AOKI  wrote:
> 
> On Fri, 17 Nov 2023 18:51:05 +0100
> tue...@freebsd.org wrote:
> 
>>> On Nov 17, 2023, at 17:06, Johan Hendriks  wrote:
>>> 
>>> I am running the rack stack for quiet some time now on a baremetal machiene 
>>> and never had problems.
>>> Also use pf.  This is a test machine so not a lot happening on it.
>>> 
>>> Are there any thing we can test? Do we have some test scripts we can run?
>> We are actually interested in feedback about using the stack in whatever
>> use case you use TCP for. The stack has been tested with the Netflix use
>> case, but not so much with others. That is why we ask for broader testing.
>> 
>> Best regards
>> Michael
> 
> Are there any difference regarding with performance between main and
> stable/14? If so, please ignore below.
> 
> I have stable/14 environment which is configured to be able to switch
> to TCP RACK and experienced huge performance loss when writing
> a large file to smbfs share on commercial NAS. CC is cubic.
> Testing large archive on the smbfs share doesn't seem to be
> affected.
> 
> Comparison between default (freebsd) and rack TCP stack using
> sysutils/clone on stable/14 at commit 7d1321288ad9, amd64.
> Last 3 lines of outputs from clone (upload to NAS) are shown.
Thank you very much for testing. This is what we are looking
for. Would it be possible to repeat the test using NewReno as
the CC?

Best regards
Michael
> 
> Before switching to rack:
> 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> Unmount the smbfs share, switch to rack, and after remount:
> 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> Switch back to freebsd (default) without unmounting:
> 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> Unmount and remount the smbfs share:
> 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> 
> Regards.
> 
> -- 
> Tomoaki AOKI




Re: Request for Testing: TCP RACK

2023-11-17 Thread Tomoaki AOKI
On Fri, 17 Nov 2023 18:51:05 +0100
tue...@freebsd.org wrote:

> > On Nov 17, 2023, at 17:06, Johan Hendriks  wrote:
> > 
> > I am running the rack stack for quiet some time now on a baremetal machiene 
> > and never had problems.
> > Also use pf.  This is a test machine so not a lot happening on it.
> > 
> > Are there any thing we can test? Do we have some test scripts we can run?
> We are actually interested in feedback about using the stack in whatever
> use case you use TCP for. The stack has been tested with the Netflix use
> case, but not so much with others. That is why we ask for broader testing.
> 
> Best regards
> Michael

Are there any difference regarding with performance between main and
stable/14? If so, please ignore below.

I have stable/14 environment which is configured to be able to switch
to TCP RACK and experienced huge performance loss when writing
a large file to smbfs share on commercial NAS. CC is cubic.
Testing large archive on the smbfs share doesn't seem to be
affected.

Comparison between default (freebsd) and rack TCP stack using
sysutils/clone on stable/14 at commit 7d1321288ad9, amd64.
Last 3 lines of outputs from clone (upload to NAS) are shown.

Before switching to rack:
1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
Leaked memory: 0 bytes
No errors occured.

Unmount the smbfs share, switch to rack, and after remount:
1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s
Leaked memory: 0 bytes
No errors occured.

Switch back to freebsd (default) without unmounting:
1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s
Leaked memory: 0 bytes
No errors occured.

Unmount and remount the smbfs share:
1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
Leaked memory: 0 bytes
No errors occured.


Regards.

-- 
Tomoaki AOKI



Re: Request for Testing: TCP RACK

2023-11-17 Thread tuexen
> On Nov 17, 2023, at 17:06, Johan Hendriks  wrote:
> 
> I am running the rack stack for quiet some time now on a baremetal machiene 
> and never had problems.
> Also use pf.  This is a test machine so not a lot happening on it.
> 
> Are there any thing we can test? Do we have some test scripts we can run?
We are actually interested in feedback about using the stack in whatever
use case you use TCP for. The stack has been tested with the Netflix use
case, but not so much with others. That is why we ask for broader testing.

Best regards
Michael
> 
> 
> 
> 




Re: Request for Testing: TCP RACK

2023-11-17 Thread Johan Hendriks
I am running the rack stack for quiet some time now on a baremetal 
machiene and never had problems.

Also use pf.  This is a test machine so not a lot happening on it.

Are there any thing we can test? Do we have some test scripts we can run?






Re: Request for Testing: TCP RACK

2023-11-17 Thread Alexander Leidinger

Am 2023-11-17 14:29, schrieb void:

On Thu, Nov 16, 2023 at 10:13:05AM +0100, tue...@freebsd.org wrote:


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


Hi, thank you for this.

https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ 
mentions

this needs to be set in /etc/src.conf :

WITH_EXTRA_TCP_STACKS=1

Is this still the case? Context here is -current both in a vm and bare
metal, on various machines, on various connections, from DSL to 10Gb.


On a recent -current: this is not needed anymore, it is part of the 
defaults now. But you may still compile the kernel with "option TCPHPTS" 
(until it's added to the defaults too).


Is there a method (yet) for enabling this functionality in various 
-RELENG

maybe where one can compile in a vm built for that purpose, then
transferring to the production vm?


Copy the kernel which was build according to the acticle from klara 
systems to your target VM.



Would it be expected to work on arm64?


Yes (I use it on an ampere VM in the cloud).

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


signature.asc
Description: OpenPGP digital signature


Re: Request for Testing: TCP RACK

2023-11-17 Thread Herbert J. Skuhra
Hi,

On Fri, Nov 17, 2023 at 02:46:52PM +0100, Olivier Cochard-Labbé wrote:
> On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra  wrote:
> 
> >
> > 1. It even fails with a simple pf.conf:
> >pass in all
> >pass out all
> >
> > 2. Fetching port distfiles also failed.
> >
> > 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> >
> >
> I can't reproduce it with pfctl too (same igb drivers with default RXCSUM
> enabled).
> 
> $ cat /etc/pf.conf
> pass in all
> pass out all
> $ service pf onestart
> Enabling pf
> .
> $ pfctl -sr
> pass in all flags S/SA keep state
> pass out all flags S/SA keep state
> $ sysctl net.inet.tcp.functions_default
> net.inet.tcp.functions_default: rack
> $ ifconfig igb0 | grep option
> 
> options=4e523bb
> nd6 options=21
> 
> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
> working
> 
> What is your igb chipset exactly  ? (pciconf -lv | grep -B 3 -F "network")

igb0@pci0:41:0:0:   class=0x02 rev=0x03 hdr=0x00 vendor=0x8086 
device=0x1533 subvendor=0x1849 subdevice=0x1533
vendor = 'Intel Corporation'
device = 'I210 Gigabit Network Connection'
class  = network

> What is your netstat -ss output ?

tcp:
946 packets sent
933 data packets (41681 bytes)
7946 ack-only packets (2 delayed)
1 control packet
999 packets received
860 acks (for 41681 bytes)
910 packets (118790 bytes) received in-sequence
12 completely duplicate packets (17136 bytes)
1 connection request
1 connection established (including accepts)
1 time used RTT from hostcache
1 time used RTT variance from hostcache
1 connection closed (including 1 drop)
1 connection updated cached RTT on close
1 connection updated cached RTT variance on close
862 segments updated rtt (of 847 attempts)
71 correct ACK header predictions
124 correct data packet header predictions
7910 SACK options (SACK blocks) sent
TCP connection count by state:
7 connections in LISTEN state
1 connection  in ESTABLISHED state
udp:
39 datagrams received
39 delivered
39 datagrams output
ip:
80 total packets received
23 packets for this host
23 packets sent from this host
icmp:
ICMP address mask responses are disabled
igmp:
arp:
ip6:
933 total packets received
931 packets for this host
8891 packets sent from this host
Input histogram:
TCP: 915
UDP: 16
ICMP6: 2
Mbuf statistics:
870 one mbuf
63 one ext mbuf
0 two or more ext mbuf
source addresses on an outgoing I/F
2 link-locals
3 globals
source addresses of same scope
2 link-locals
3 globals
Source addresses selection rule applied:
5 first candidate
3 appropriate scope
icmp6:
Output histogram:
neighbor solicitation: 2
Input histogram:
neighbor advertisement: 2
Histogram of error messages to be generated:
rip6:


Thanks.

-- 
Herbert



Re: Request for Testing: TCP RACK

2023-11-17 Thread Olivier Cochard-Labbé
On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra  wrote:

>
> 1. It even fails with a simple pf.conf:
>pass in all
>pass out all
>
> 2. Fetching port distfiles also failed.
>
> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
>
>
> I can't reproduce it with pfctl too (same igb drivers with default RXCSUM
enabled).

$ cat /etc/pf.conf
pass in all
pass out all
$ service pf onestart
Enabling pf
.
$ pfctl -sr
pass in all flags S/SA keep state
pass out all flags S/SA keep state
$ sysctl net.inet.tcp.functions_default
net.inet.tcp.functions_default: rack
$ ifconfig igb0 | grep option

options=4e523bb
nd6 options=21

$ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
working

What is your igb chipset exactly  ? (pciconf -lv | grep -B 3 -F "network")
What is your netstat -ss output ?


Re: Request for Testing: TCP RACK

2023-11-17 Thread Herbert J. Skuhra
Hi,

On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> 
> > 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?

1. It even fails with a simple pf.conf:
   pass in all
   pass out all

2. Fetching port distfiles also failed.

3. If I disable rxcsum on the ethernet adapter (igb0) it works.

Thanks.

--
Herbert



Re: Request for Testing: TCP RACK

2023-11-17 Thread void

On Thu, Nov 16, 2023 at 10:13:05AM +0100, tue...@freebsd.org wrote:


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


Hi, thank you for this.

https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ mentions
this needs to be set in /etc/src.conf :

WITH_EXTRA_TCP_STACKS=1

Is this still the case? Context here is -current both in a vm and bare
metal, on various machines, on various connections, from DSL to 10Gb.

Is there a method (yet) for enabling this functionality in various -RELENG
maybe where one can compile in a vm built for that purpose, then
transferring to the production vm?

Would it be expected to work on arm64?

What testing would you like doing?
--



Re: Request for Testing: TCP RACK

2023-11-16 Thread tuexen
> 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




Re: Request for Testing: TCP RACK

2023-11-16 Thread tuexen
> 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

2023-11-16 Thread tuexen
> 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

2023-11-16 Thread Herbert J. Skuhra
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

2023-11-16 Thread Olivier Cochard-Labbé
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

2023-11-16 Thread Marek Zarychta

W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze:

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

That's really good news and long-awaited change. Thank you.

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.


Yes, please do it, at least for CURRENT. Last problem I have spotted 
with RACK was fixed in June: it was missing support TCP-MD5:


https://cgit.freebsd.org/src/commit/?id=02b885b09d1e90574162a1442b9ede06cef2b13a

We switched to RACK since upgrading to early stable/13 and genuinely 
appreciate this gift from Netflix. The performance improvement is 
invaluable, both in a lossy LAN and on a long-haul overseas TCP connection.



Please let me know if you have any questions.


Are any MFCs planned, especially to stable/14 ? Now, when stable/14 is 
almost in sync with main aka CURRENT it's an optimal time for such a 
MFC. When the change hits stable/14, it would be possible to test it 
extensively and have it fully functional in 14.1-RELEASE.


Best regards

--
Marek Zarychta


Re: Request for Testing: TCP RACK

2023-11-16 Thread Herbert J. Skuhra
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

2023-11-16 Thread Herbert J. Skuhra
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



Request for Testing: TCP RACK

2023-11-16 Thread tuexen
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





I've shown the following 3 items via kyua testing with the latest snapshot of armv7 14 on a OrangePi+2Ed (Cortex-A7), a panic included

2023-08-05 Thread Mark Millard
I've set up armv7 boot media based on:

http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230803-8a5c836b51ce-264491.img.xz

for the OrangePi+2Ed (it also handles the RPi2B v1.1).

No builds by me. The ports installed are from the FreeBSD servers and
are for kyua activity's use, other than gdb.

The presence of panic and large count of hours waiting for
timeouts explain why this report only covers specific issues
and no a full kyua run at this point.

[I'll note that this activity has been driven by attempted testing
of lib32, where I then end up with the question "is this unique to
lib32?" and so end up looking at armv7 chroot on aarch64. More
problems there --and so the question "is this unique to armv7 use
on aarch64". This leads to looking at Cortex-A7 armv7 (a fully
native armv7) context for comparison. I've had to wander well
outside my original intended testing contexts and have ended up
blocked in each type of context. Given the original goal, I'm
sticking to main, not stable/* nor releng/*.* .]



EXAMPLE issue: *.py based kyua testing problem for armv7 main:

The kyua *.py based tests on armv7 main get long timeouts
when python executes as armv7 code, even for very simple
tests:

# /usr/bin/kyua test -k /usr/tests/Kyuafile 
examples/test_examples.py:TestExampleSimple::test_with_cleanup
examples/test_examples.py:TestExampleSimple::test_with_cleanup  ->  broken: 
Test case body timed out  [300.062s]

Results file id is usr_tests.20230806-003823-404601
Results saved to /root/.kyua/store/results.usr_tests.20230806-003823-404601.db

0/1 passed (1 failed)

This happens even on the cortex-A7 system, no lib32 involved,
no chroot involved.

NOTE:
There are a lot of these tests and some have timeouts set at
3600s, others at 1800s and 1200s. Lots at 300s. If a full
kyua run completed, it would take a very long time to do so.
Kyua classifies all these long-timeout tests as broken. So
lots of testing is not happening, despte the time taken.

There are 10 or so:

->  skipped: comment me to run the test

and one each of each of:

->  skipped: Current architecture 'armv7' not supported
__test_cases_list__  ->  broken: Test program did not exit cleanly
__test_cases_list__  ->  broken: Test case list wrote to stderr

I do not know if this promblem type might be somehow tied to the
openssl 3 compatibility issue(s) that the ports python's currently
have for main. If it is, the error handling seems to not be
directly reporting anything that makes it obvious.



EXAMPLE armv7 related 'Alignment Fault' on read panic:

The kyua sys/netinet6/exthdr:exthdr panic has a different backtrace than
I've had from my builds, udp_input this time:

# /usr/bin/kyua test -k /usr/tests/Kyuafile sys/netinet6/exthdr:exthdr
sys/netinet6/exthdr:exthdr  ->  warning: KLD '/boot/kernel/if_epair.ko' is 
newer than the linker.hints file
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xe014ab00
FSR=0001, FAR=da87f00e, spsr=2013
r0 =, r1 =0001, r2 =0001, r3 =0134
r4 =, r5 =0134, r6 =da87f00e, r7 =da87f022
r8 =0134, r9 =c0918b04, r10=0014, r11=e014ac28
r12=, ssp=e014ab90, slr=c04534f4, pc =c048b34c

panic: Fatal abort
cpuid = 1
time = 1691281420
KDB: stack backtrace:
db_trace_self() at db_trace_self
 pc = 0xc05ecde4  lr = 0xc0079c70 (db_trace_self_wrapper+0x30)
 sp = 0xe014a8b8  fp = 0xe014a9d0
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
 pc = 0xc0079c70  lr = 0xc02e99a0 (vpanic+0x140)
 sp = 0xe014a9d8  fp = 0xe014a9f8
 r4 = 0x0100  r5 = 0x
 r6 = 0xc07597e2  r7 = 0xc0aeaec8
vpanic() at vpanic+0x140
 pc = 0xc02e99a0  lr = 0xc02e9780 (doadump)
 sp = 0xe014aa00  fp = 0xe014aa04
 r4 = 0xe014ab00  r5 = 0x0013
 r6 = 0xda87f00e  r7 = 0x0001
 r8 = 0x0001  r9 = 0xe0773ba0
r10 = 0xda87f00e
doadump() at doadump
 pc = 0xc02e9780  lr = 0xc0611184 (abort_align)
 sp = 0xe014aa0c  fp = 0xe014aa38
 r4 = 0xda87f00e  r5 = 0xe014aa04
 r6 = 0xc02e9780 r10 = 0xe014aa0c
abort_align() at abort_align
 pc = 0xc0611184  lr = 0xc06111f8 (abort_align+0x74)
 sp = 0xe014aa40  fp = 0xe014aa58
 r4 = 0x0013 r10 = 0xda87f00e
abort_align() at abort_align+0x74
 pc = 0xc06111f8  lr = 0xc0610e18 (abort_handler+0x498)
 sp = 0xe014aa60  fp = 0xe014aaf8
 r4 = 0x r10 = 0xda87f00e
abort_handler() at abort_handler+0x498
 pc = 0xc0610e18  lr = 0xc05ef6ac (exception_exit)
 sp = 0xe014ab00  fp = 0xe014ac28
 r4 = 0x  r5 = 0x0134
 r6 = 0xda87f00e  r7 = 0xda87f022
 r8 = 0x0134  r9 = 0xc0918b04
r10 = 0x0014
exception_exit() at exception_exit
 pc = 0xc05ef6ac  lr = 0xc04534f4 (ip_input+0x404)
 sp = 0xe014ab90  fp = 0xe014ac28
   

FYI for aarch64/armv7 lib32: armv7 kyua test sys/net/if_bridge_test:gif with preloaded if_bridge.ko still panics in my style of testing

2023-07-29 Thread Mark Millard
I finally got around to testing lib32 some more, first
trying the panic case that I'd gotten in early testing.
The below is without any special lib32 patching for
testing, just my normal non-debug environment updated
to a lib32-present aarch64 FreeBSD vintage.

Reminder: /usr/obj/DESTDIRs/main-CA7-chroot/ contains an
armv7 installworld distrib-dirs distribution DB_FROM_SRC=1
result. (It also has various ports installed.)

# ~/prekyua-kldloads.sh
. . .
# env \
> LD_32_LIBRARY_PATH=/usr/obj/DESTDIRs/main-CA7-chroot/lib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/libexec/rtld-elf\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libxo\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/csu/dynamiclib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/tls\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/stdlib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libthr/dlopen\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/lib-dynload\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/CORE\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/auto \
> PATH=/usr/obj/DESTDIRs/main-CA7-chroot/sbin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/sbin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/sbin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/root/bin \
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua test \
> -k /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/Kyuafile 
> sys/net/if_bridge_test:gif
sys/net/if_bridge_test:gif  ->  Jul 29 21:29:16 CA72-16Gp-ZFS dhclient[56641]: 
epair0a: not found
Jul 29 21:29:16 CA72-16Gp-ZFS dhclient[56641]: exiting.
Fatal data abort:
  x0: 0xa0275306c560
  x1: 0xa027f9d053d2
  x2: 0x002a
  x3: 0xa0275306c560
  x4: 0xa027f9d053fc
  x5: 0xa0275306c58a
  x6: 0x3ec2
  x7: 0x010006085ba958bc
  x8: 0x002a
  x9: 0x002a
 x10: 0x0008010006085ba9
 x11: 0x58bc3ec201000406
 x12: 0x016433c65ba9
 x13: 0x026433c6
 x14: 0x00ff
 x15: 0x289f
 x16: 0x0002d056b370 (_DYNAMIC + 0x370)
 x17: 0x00598110 (m_dup + 0x0)
 x18: 0x0002801e94a0
 x19: 0x0001
 x20: 0x
 x21: 0x
 x22: 0x00d95000 (vop_spare3_desc + 0x18)
 x23: 0xa0275306c500
 x24: 0xa0275306c500
 x25: 0x00a0
 x26: 0x0002
 x27: 0x
 x28: 0xa0275306c500
 x29: 0x0002801e94c0
  sp: 0x0002801e94a0
  lr: 0x00598308 (m_dup + 0x1f8)
 elr: 0x00598160 (m_dup + 0x50)
spsr: 0x2045
 far: 0x001c
 esr: 0x9604
panic: vm_fault failed: 0x00598160 error 1
cpuid = 14
time = 1690691356
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x13c
panic() at panic+0x44
data_abort() at data_abort+0x2fc
handle_el1h_sync() at handle_el1h_sync+0x14
--- exception, esr 0x9604
m_dup() at m_dup+0x50
bridge_input() at bridge_input+0x17c
gif_input() at gif_input+0x2dc
in_gif_input() at in_gif_input+0x5c
encap_input() at encap_input+0xfc
encap4_input() at encap4_input+0x30
ip_input() at ip_input+0x5ac
netisr_dispatch_src() at netisr_dispatch_src+0xf8
ether_demux() at ether_demux+0x14c
ether_nh_input() at ether_nh_input+0x39c
netisr_dispatch_src() at netisr_dispatch_src+0xf8
ether_input() at ether_input+0x50
epair_tx_start_deferred() at epair_tx_start_deferred+0x110
taskqueue_run_locked() at taskqueue_run_locked+0x198
taskqueue_thread_loop() at taskqueue_thread_loop+0x130
fork_exit() at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 0 tid 1028122 ]
Stopped at  kdb_enter+0x44: str xzr, [x19, #3328]

For reference:

# uname -apKU
FreeBSD CA72-16Gp-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 #102 
main-n264334-215bab7924f6-dirty: Wed Jul 26 02:02:48 PDT 2023 
root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
 arm64 aarch64 1400093 1400093



===
Mark Millard
marklmi at yahoo.com




Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-12 Thread Enji Cooper

> On Jul 10, 2023, at 3:27 PM, Mark Millard  wrote:
> 
> On Jul 10, 2023, at 15:03, Mark Millard  > wrote:
> 
>> On Jul 10, 2023, at 11:42, The Doctor  wrote:
>> 
>>> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
 The subject line's question was prompted by
 . . ./hazmat/bindings/_openssl.abi3.so related notices
 in a kyua report:
 
 # kyua report --verbose 
 --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
  2>&1 | grep "Undefined symbol" | sort -u
 +ImportError: 
 /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
  Undefined symbol "ERR_GET_FUNC"
 ImportError: 
 /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
  Undefined symbol "ERR_GET_FUNC"
 ImportError: 
 /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
  Undefined symbol "ERR_GET_FUNC"
 
 It is possible that this is related to some oddities of my
 context for this. But I figured I'd ask the general question
 anyway.
 
>>> 
>>> No! The problem is that Python is calling an openssl 1.X function
>>> which is dropped in Opensss 3.X
>>> 
>>> Python nedds to fix that issue.
>> 
>> Well:
>> 
>> # strings 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
>>  | grep -i "3\.[0-9]*\.[0-9]"
>> OpenSSL 3.0.9 30 May 2023
>> 3.4.8
>> 
>> From what I read, 3.4.8 is too old and is known to have this issue and this
>> was fixed in a later version. I see references to "cryptography" needing to
>> be "at least 35.0.0 for OpenSSL 3.0 support" instead of "3.4.8" as one place
>> put it.
>> 
>> I've no clue of the details for python3.9 vs. python3.10 or python3.11 for
>> containing a sufficiently modern "cryptography" already in FreeBSD ports
>> (vs. not). But this may be more of a port-update issue than an up-stream
>> python issue -- or possibly just a "use python 3.? or later" issue for
>> some value for "?".
>> 
> 
> 35.0.0 of cryptography dates back to 2021-09-29.
> Current for cryptography is 41.0.1 (2023-06-01).
> It claims: "It supports Python 3.7+ and PyPy3
> 7.3.10+."
> 
> security/py-cryptography is at 3.4.8 (2021-08-24)
> for py39-cryptography and is, in-part, a FreeBSD
> ports issue as far as I can tell.
> 
> Looking, it seems it is at 3.4.8 for all @${PY_FLAVOR}
> instances. So trying python310 or python311 might
> well do no good for openssl 3.0 compatibility if they
> use security/py-cryptography .
> 
> (Note: I build my own ports via poudriere-devel .)

py-cryptography in ports doesn’t support OpenSSL 3. Please see this issue for 
more details: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853 
 .
Thanks,
-Enji


signature.asc
Description: Message signed with OpenPGP


Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-10 Thread Mark Millard
On Jul 10, 2023, at 15:03, Mark Millard  wrote:

> On Jul 10, 2023, at 11:42, The Doctor  wrote:
> 
>> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
>>> The subject line's question was prompted by
>>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>>> in a kyua report:
>>> 
>>> # kyua report --verbose 
>>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>>  2>&1 | grep "Undefined symbol" | sort -u
>>> +ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> 
>>> It is possible that this is related to some oddities of my
>>> context for this. But I figured I'd ask the general question
>>> anyway.
>>> 
>> 
>> No! The problem is that Python is calling an openssl 1.X function
>> which is dropped in Opensss 3.X
>> 
>> Python nedds to fix that issue.
> 
> Well:
> 
> # strings 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
>  | grep -i "3\.[0-9]*\.[0-9]"
> OpenSSL 3.0.9 30 May 2023
> 3.4.8
> 
> From what I read, 3.4.8 is too old and is known to have this issue and this
> was fixed in a later version. I see references to "cryptography" needing to
> be "at least 35.0.0 for OpenSSL 3.0 support" instead of "3.4.8" as one place
> put it.
> 
> I've no clue of the details for python3.9 vs. python3.10 or python3.11 for
> containing a sufficiently modern "cryptography" already in FreeBSD ports
> (vs. not). But this may be more of a port-update issue than an up-stream
> python issue -- or possibly just a "use python 3.? or later" issue for
> some value for "?".
> 

35.0.0 of cryptography dates back to 2021-09-29.
Current for cryptography is 41.0.1 (2023-06-01).
It claims: "It supports Python 3.7+ and PyPy3
7.3.10+."

security/py-cryptography is at 3.4.8 (2021-08-24)
for py39-cryptography and is, in-part, a FreeBSD
ports issue as far as I can tell.

Looking, it seems it is at 3.4.8 for all @${PY_FLAVOR}
instances. So trying python310 or python311 might
well do no good for openssl 3.0 compatibility if they
use security/py-cryptography .

(Note: I build my own ports via poudriere-devel .)

===
Mark Millard
marklmi at yahoo.com




Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-10 Thread Mark Millard
On Jul 10, 2023, at 11:42, The Doctor  wrote:

> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
>> The subject line's question was prompted by
>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>> in a kyua report:
>> 
>> # kyua report --verbose 
>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>  2>&1 | grep "Undefined symbol" | sort -u
>> +ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> 
>> It is possible that this is related to some oddities of my
>> context for this. But I figured I'd ask the general question
>> anyway.
>> 
> 
> No! The problem is that Python is calling an openssl 1.X function
> which is dropped in Opensss 3.X
> 
> Python nedds to fix that issue.

Well:

# strings 
/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
 | grep -i "3\.[0-9]*\.[0-9]"
OpenSSL 3.0.9 30 May 2023
3.4.8

From what I read, 3.4.8 is too old and is known to have this issue and this
was fixed in a later version. I see references to "cryptography" needing to
be "at least 35.0.0 for OpenSSL 3.0 support" instead of "3.4.8" as one place
put it.

I've no clue of the details for python3.9 vs. python3.10 or python3.11 for
containing a sufficiently modern "cryptography" already in FreeBSD ports
(vs. not). But this may be more of a port-update issue than an up-stream
python issue -- or possibly just a "use python 3.? or later" issue for
some value for "?".


===
Mark Millard
marklmi at yahoo.com




Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-10 Thread The Doctor
On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
> The subject line's question was prompted by
> . . ./hazmat/bindings/_openssl.abi3.so related notices
> in a kyua report:
> 
> # kyua report --verbose 
> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>  2>&1 | grep "Undefined symbol" | sort -u
> +ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> 
> It is possible that this is related to some oddities of my
> context for this. But I figured I'd ask the general question
> anyway.
>

No! The problem is that Python is calling an openssl 1.X function
which is dropped in Opensss 3.X

Python nedds to fix that issue.

> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

-- 
Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
"We should do good unless it inconveniences us," is not righteous thinking. 
-unknown Beware https://mindspring.com



Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-10 Thread Mark Millard
On Jul 10, 2023, at 10:55, Mark Millard  wrote:

> On Jul 10, 2023, at 09:45, Mike Karels  wrote:
> 
>> On 10 Jul 2023, at 10:56, Mark Millard wrote:
>> 
>>> The subject line's question was prompted by
>>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>>> in a kyua report:
>>> 
>>> # kyua report --verbose 
>>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>>  2>&1 | grep "Undefined symbol" | sort -u
>>> +ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> 
>>> It is possible that this is related to some oddities of my
>>> context for this. But I figured I'd ask the general question
>>> anyway.
>> 
>> I haven't seen this.  My v7 environments (chroot and /usr/lib32) have
>> only libssl.so.3, not .111, so they must be using OpenSSL 3.0.
> 
> But is the phython3 use by kyua of aarch64 code? armv7 code?
> 
> # file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, 
> ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
> /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped
> 
> So: armv7 for my lib32 testing activity.
> 
>> Which version of kyua is this running (32 or 64 bit)?
> 
> armv7 (so: 32-bit). This is using my way of causing more
> code to be armv7 instead of aarch64 processes for lib32
> testing than I expect your testing technique ends up
> with.
> 
> # file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, 
> ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
> /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped
> 
> For reference:
> 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so.30
> 
> As for the aarch4 boot environment:
> 
> /usr/lib/libssl.so
> /usr/lib/libssl.so.30

I forgot to list:

/usr/lib32/libssl.so.30
/usr/lib32/libssl.so

Sorry for the confusion.

> There are no *.111* files on the system other than some
> old log files or other archiving of old things in 2
> separate old-stuff directory trees that are not in
> use.


===
Mark Millard
marklmi at yahoo.com




Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-10 Thread Mark Millard
On Jul 10, 2023, at 09:45, Mike Karels  wrote:

> On 10 Jul 2023, at 10:56, Mark Millard wrote:
> 
>> The subject line's question was prompted by
>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>> in a kyua report:
>> 
>> # kyua report --verbose 
>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>  2>&1 | grep "Undefined symbol" | sort -u
>> +ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> 
>> It is possible that this is related to some oddities of my
>> context for this. But I figured I'd ask the general question
>> anyway.
> 
> I haven't seen this.  My v7 environments (chroot and /usr/lib32) have
> only libssl.so.3, not .111, so they must be using OpenSSL 3.0.

But is the phython3 use by kyua of aarch64 code? armv7 code?

# file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, ARM, 
EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
/libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped

So: armv7 for my lib32 testing activity.

> Which version of kyua is this running (32 or 64 bit)?

armv7 (so: 32-bit). This is using my way of causing more
code to be armv7 instead of aarch64 processes for lib32
testing than I expect your testing technique ends up
with.

# file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, ARM, 
EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
/libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped

For reference:

/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so
/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so.30

As for the aarch4 boot environment:

/usr/lib/libssl.so
/usr/lib/libssl.so.30

There are no *.111* files on the system other than some
old log files or other archiving of old things in 2
separate old-stuff directory trees that are not in
use.

===
Mark Millard
marklmi at yahoo.com




Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-10 Thread Mike Karels
On 10 Jul 2023, at 10:56, Mark Millard wrote:

> The subject line's question was prompted by
> . . ./hazmat/bindings/_openssl.abi3.so related notices
> in a kyua report:
>
> # kyua report --verbose 
> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>  2>&1 | grep "Undefined symbol" | sort -u
> +ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
>
> It is possible that this is related to some oddities of my
> context for this. But I figured I'd ask the general question
> anyway.

I haven't seen this.  My v7 environments (chroot and /usr/lib32) have
only libssl.so.3, not .111, so they must be using OpenSSL 3.0.

Which version of kyua is this running (32 or 64 bit)?

Mike

> ===
> Mark Millard
> marklmi at yahoo.com



Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

2023-07-10 Thread Mark Millard
The subject line's question was prompted by
. . ./hazmat/bindings/_openssl.abi3.so related notices
in a kyua report:

# kyua report --verbose 
--results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
 2>&1 | grep "Undefined symbol" | sort -u
+ImportError: 
/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "ERR_GET_FUNC"
ImportError: 
/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "ERR_GET_FUNC"
ImportError: 
/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "ERR_GET_FUNC"

It is possible that this is related to some oddities of my
context for this. But I figured I'd ask the general question
anyway.

===
Mark Millard
marklmi at yahoo.com




Options for production testing under current(samba slow)

2022-11-05 Thread Dan The Man



cd /usr/src/sys/amd64/conf
cp GENERIC-NODEBUG MYKERNEL;
(add: options BHYVE_SNAPSHOT)
cd /usr/src
make -j12 buildworld -DWITH_BHYVE_SNAPSHOT -DWITH_MALLOC_PRODUCTION
make -j12 buildkernel KERNCONF=MYKERNEL
make installkernel KERNCONF=MYKERNEL
etc

Been playing with current lately mostly to use bhyve suspend/resume(which 
works fine btw, other than core dumps if I left a cd device in there with 
an ISO etc).


I have noticed on samba I am loosing 100-200MB/s transfer speeds now over 
10gigabit ix0 device, I am wondering if I need more options than

-DWITH_MALLOC_PRODUCTION?


Dan.

--
Dan The Man
CEO & Founder
Websites, Domains and Everything else
http://www.SunSaturn.com/aboutus.php
Email: d...@sunsaturn.com
PGP Key: https://SunSaturn.com/pgp.txt
A1A7 6E84 FB0B 8994 C3B5  A1BA FF6F 4997 7311 C386



Re: Testing 14-CURRENT-f44280bf5fb on aarch64

2022-05-10 Thread Hans Petter Selasky

On 5/10/22 09:37, Daniel Morante wrote:
Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May 
10 02:52:27 EDT 2022) and removed the sysctl option 
(hw.usb.disable_enumeration=1).


Still seeing the problem.  The below just endlessly prints out on the 
console:


```

FreeBSD/arm64 (mars.morante.com) (ttyu0)

login: ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub_attach: port 1 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 2 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 3 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 4 power on or off failed, USB_ERR_IOERROR
uhub4: 4 ports with 4 removable, self powered
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 1
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 2
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 3
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 4
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
```



Hi,

Does it help to do a "usbconfig -d X.Y reset" of the parent USB HUB of 
the failing one, I guess this is ugen0.1 .


--HPS




Re: Testing 14-CURRENT-f44280bf5fb on aarch64

2022-05-10 Thread Daniel Morante
Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May 
10 02:52:27 EDT 2022) and removed the sysctl option 
(hw.usb.disable_enumeration=1).


Still seeing the problem.  The below just endlessly prints out on the 
console:


```

FreeBSD/arm64 (mars.morante.com) (ttyu0)

login: ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub_attach: port 1 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 2 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 3 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 4 power on or off failed, USB_ERR_IOERROR
uhub4: 4 ports with 4 removable, self powered
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 1
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 2
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 3
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 4
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
```

On 5/4/2022 4:10 AM, Hans Petter Selasky wrote:

On 5/4/22 09:49, Daniel Morante wrote:
I'm still using the sysctl option "hw.usb.disable_enumeration=1" to 
prevent the USB devices from disconnecting/reconnecting every few 
seconds.  Other than that the improvement in stability with 
14-CURRENT on aarach64 on this hardware is much better since the last 
time I tried, back in late February 2022.


Hi Daniel,

Could you try the very latest 14-current as of now? I've made a couple 
of USB fixes which may fix the issue you are seeing.


--HPS





Re: Testing 14-CURRENT-f44280bf5fb on aarch64

2022-05-04 Thread Hans Petter Selasky

On 5/4/22 09:49, Daniel Morante wrote:
I'm still using the sysctl option "hw.usb.disable_enumeration=1" to 
prevent the USB devices from disconnecting/reconnecting every few 
seconds.  Other than that the improvement in stability with 14-CURRENT 
on aarach64 on this hardware is much better since the last time I tried, 
back in late February 2022.


Hi Daniel,

Could you try the very latest 14-current as of now? I've made a couple 
of USB fixes which may fix the issue you are seeing.


--HPS



Testing 14-CURRENT-f44280bf5fb on aarch64

2022-05-04 Thread Daniel Morante
I have been testing 14-CURRENT-f44280bf5fb for the last few days and so 
far it's been okay on my hardware (Cavium ThunderX2). Most of the 
details of the system are saved in 
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-f44280bf5fb. 
I've only had one kernel panic (seen under panic1.txt).


I'm still using the sysctl option "hw.usb.disable_enumeration=1" to 
prevent the USB devices from disconnecting/reconnecting every few 
seconds.  Other than that the improvement in stability with 14-CURRENT 
on aarach64 on this hardware is much better since the last time I tried, 
back in late February 2022.


I figured I would share my experience since I don't know what's the best 
way for me to help with testing new hardware with FreeBSD (besides 
opening PR's for hardware that's not detected).






Testing needed:)

2019-11-25 Thread Toomas Soome


Hi!

Can someone with arm media file path type of storage device and someone with 
apple UEFI 1.10 test https://reviews.freebsd.org/D22553 please:)

Other tests are also very welcome:)

thanks,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[CALL FOR TESTING][PATCH]: Intel Comet Lake and Ice Lake HD Audio Support

2019-10-05 Thread Neel Chauhan

Hi freebsd-current@ mailing list,

I have a patch which adds support for the HD Audio Codecs for the Intel 
Comet Lake and Ice Lake PCHs. This is similar to my now-committed Cannon 
Lake HD Audio patch.


Please find below the Bugzilla and Phabricator links (both have the 
patch):


Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240871
Phabricator: https://reviews.freebsd.org/D21818

What I need is for people with systems with Comet Lake and Ice Lake PCHs 
to test this patch, and for committers to review and commit this once 
tested. This patch should work with most non-Apple Comet Lake and Ice 
Lake systems.


This is needed as unlike Cannon Lake where I had hardware (HP Spectre 
x360 2018), I lack hardware running Comet Lake and Ice Lake.


-Neel

===

https://www.neelc.org/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: FUSE Call for Testing

2019-08-09 Thread Gary Jennejohn
On Fri, 9 Aug 2019 15:38:06 +0200
Gary Jennejohn  wrote:

> On Fri, 9 Aug 2019 06:49:36 -0600
> Alan Somers  wrote:
> 
> [snip test results]
> 
> > Thanks for the report, Gary.  BTW, fusefs mounts are only
> > interruptible when mounted with "-o intr".  If you didn't use that
> > option, then the signal would only interrupt cp after the write to
> > fusefs was done.  Also, not every fuse file system supports
> > interrupts.  Looking through its sources, I don't think that
> > fusefs-ntfs does.
> >  
> 
> I'm not convinced of that.  I interrupted the 5.2GiB transfer
> several times to try out different UBLIO environment settings
> and it stopped pretty much immediately.  I also did not use
> mount but rather a direct invocation of ntfs-3g.
> 
> I suspect that ntfs-3g stops after the interrupt once it has
> flushed the UBLIO buffers.
> 

Upon reconsideration, I guess you're right.  What stopped was cp
and not necessarily ntfs-3g.  Still, ^C did what I expected.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: FUSE Call for Testing

2019-08-09 Thread Alan Somers
On Fri, Aug 9, 2019 at 7:38 AM Gary Jennejohn  wrote:
>
> On Fri, 9 Aug 2019 06:49:36 -0600
> Alan Somers  wrote:
>
> [snip test results]
>
> > Thanks for the report, Gary.  BTW, fusefs mounts are only
> > interruptible when mounted with "-o intr".  If you didn't use that
> > option, then the signal would only interrupt cp after the write to
> > fusefs was done.  Also, not every fuse file system supports
> > interrupts.  Looking through its sources, I don't think that
> > fusefs-ntfs does.
> >
>
> I'm not convinced of that.  I interrupted the 5.2GiB transfer
> several times to try out different UBLIO environment settings
> and it stopped pretty much immediately.  I also did not use
> mount but rather a direct invocation of ntfs-3g.
>
> I suspect that ntfs-3g stops after the interrupt once it has
> flushed the UBLIO buffers.
>
> --
> Gary Jennejohn (gj@)

Well, I can guarantee that the write(2) into fusefs was not
interrupted if you did not specify "-o intr".  I know, because I wrote
that code.  You would need to use "-o intr" whether you mount by
invoking mount or ntfs-3g.  But cp probably only copies a few KB to a
few hundred KB at a time.  So even without "-o intr", a signal would
probably feel fairly responsive.
-Alan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: FUSE Call for Testing

2019-08-09 Thread Gary Jennejohn
On Fri, 9 Aug 2019 06:49:36 -0600
Alan Somers  wrote:

[snip test results]

> Thanks for the report, Gary.  BTW, fusefs mounts are only
> interruptible when mounted with "-o intr".  If you didn't use that
> option, then the signal would only interrupt cp after the write to
> fusefs was done.  Also, not every fuse file system supports
> interrupts.  Looking through its sources, I don't think that
> fusefs-ntfs does.
>

I'm not convinced of that.  I interrupted the 5.2GiB transfer
several times to try out different UBLIO environment settings
and it stopped pretty much immediately.  I also did not use
mount but rather a direct invocation of ntfs-3g.

I suspect that ntfs-3g stops after the interrupt once it has
flushed the UBLIO buffers.

-- 
Gary Jennejohn (gj@)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


  1   2   3   4   5   6   7   8   9   10   >