[Bug 280386] if_bridge throws output errors under load

2024-10-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386 --- Comment #23 from pascal.guitier...@gmail.com --- (In reply to Kevin Bowling from comment #21) (In reply to Kevin Bowling from comment #22) Interesting, thanks for that. I tried changing dev.igb.0.iflib.override_ntxqs=4096 but to no eff

[Bug 280386] if_bridge throws output errors under load

2024-10-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386 --- Comment #22 from Kevin Bowling --- (In reply to Kevin Bowling from comment #21) Thinking back a bit harder one thing that might help workaround this is to increase the number of transmit descriptors.. try something like this in /boot/lo

[Bug 280386] if_bridge throws output errors under load

2024-10-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386 --- Comment #21 from Kevin Bowling --- (In reply to pascal.guitierrez from comment #20) > Do you know if this is expected behaviour or is it a problem? Caveat it has been a long time since I have been line-rating large numbers of FreeBSD sy

Re: Performance test for CUBIC in stable/14

2024-10-21 Thread void
On Mon, Oct 21, 2024 at 10:42:49AM -0400, Cheng Cui wrote: Change the subject to `Performance test for CUBIC in stable/14`, was `Re: Performance issues with vnet jails + epair + bridge`. I actually prepared two patches, one depends on the other: https://reviews.freebsd.org/D47218 << apply t

Re: Performance test for CUBIC in stable/14

2024-10-21 Thread Cheng Cui
Change the subject to `Performance test for CUBIC in stable/14`, was `Re: Performance issues with vnet jails + epair + bridge`. I actually prepared two patches, one depends on the other: https://reviews.freebsd.org/D47218 << apply this patch firstly https://reviews.freebsd.org/D47213 << a

[Bug 280386] if_bridge throws output errors under load

2024-10-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386 --- Comment #20 from pascal.guitier...@gmail.com --- (In reply to Kevin Bowling from comment #19) Thanks Kevin, yes you are right, repeating the test gets to a state where interrupts are processed on a single core and packet drops occur: