Re: TCP_FASTOPEN is absent in GENERIC

2017-01-31 Thread Patrick Kelsey
On Tue, Jan 31, 2017 at 10:53 AM, Sergey Matveychuk wrote: > Hi. > > Is there a strong reason for option TCP_FASTOPEN is absent in GENERIC > kernel? It's off by default anyway (net.inet.tcp.fastopen.enabled=0). > > Latest dns/bind* versions want it very much. > > The kernel option name is actuall

Re: all network people please review this proposal: because someone is going to commit it soon. D5017

2017-01-31 Thread Ermal Luçi
On Fri, Jan 20, 2017 at 7:15 AM, Slawa Olhovchenkov wrote: > On Fri, Jan 20, 2017 at 11:00:18PM +0800, Julian Elischer wrote: > > > Unless eri gets to it first I will. > > > > see https://reviews.freebsd.org/D5017 > > > > If you have a server, you can put an arbitrary number of clients on > > the

Re: Disappointing packets-per-second performance results on a Dell, PE R530

2017-01-31 Thread Jordan Caraballo
Hi Oliver, my bad, I missed that one. Here is the info: * Switch with 48x 10G ports and 12x 40G ports was used * (48) 10G connected nodes were used. * (24) nodes on each side of the firewall * Packet per second (PPS) tests were run using 'iperf' * Bandwidth tests were run using 'nuttcp' * Paralle

Re: Disappointing packets-per-second performance results on a Dell, PE R530

2017-01-31 Thread Olivier Cochard-Labbé
On Tue, Jan 31, 2017 at 6:53 PM, Jordan Caraballo < jordancaraball...@gmail.com> wrote: > This are the most recent stats. No advances so far. The system has > -Current right now. > > Any help or feedback would be appreciated. > > ​I've tried: But you didn't answer my previous question. How do you

Re: Disappointing packets-per-second performance results on a Dell, PE R530

2017-01-31 Thread Kevin Bowling
I would also suggest increasing the holdoff timer for the Chelsio and see what happens: sysctl dev.t5nex.0.holdoff_timer_idx_10G=3 sysctl dev.t5nex.0.holdoff_timer_idx_10G=4 sysctl dev.t5nex.0.holdoff_timer_idx_10G=5 On Tue, Jan 31, 2017 at 11:10 AM, Slawa Olhovchenkov wrote: > On Tue, Jan 31,

[Bug 196361] Constrain IPv6 routes to each FIB (Consistent with IPv4 route behaviour)

2017-01-31 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196361 --- Comment #15 from commit-h...@freebsd.org --- A commit references this bug: Author: asomers Date: Tue Jan 31 20:13:50 UTC 2017 New revision: 313025 URL: https://svnweb.freebsd.org/changeset/base/313025 Log: Add tests for multi-fib IPv

[Bug 196361] Constrain IPv6 routes to each FIB (Consistent with IPv4 route behaviour)

2017-01-31 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196361 --- Comment #14 from jhujh...@adjectivism.org --- (In reply to Alan Somers from comment #13) Hi Alan, Sorry for the radio silence - I can fix the test case and submit for formal code review in the next couple of days if you'd like. -- Yo

[Bug 196361] Constrain IPv6 routes to each FIB (Consistent with IPv4 route behaviour)

2017-01-31 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196361 --- Comment #13 from Alan Somers --- I've fully reviewed jhujhiti's testcases. Apart from using the wrong syntax to delete an IPv6 route in same_ip_multiple_ifaces_inet6, it looks good. I'll commit it with minor changes. -- You are rece

Re: Disappointing packets-per-second performance results on a Dell,PE R530

2017-01-31 Thread Slawa Olhovchenkov
On Tue, Jan 31, 2017 at 01:53:15PM -0400, Jordan Caraballo wrote: > This are the most recent stats. No advances so far. The system has > -Current right now. This is like you have only one flow: only CPU 26 and 27 loaded. Use different benchmark, create multiple IP flow (w/ different source/dest

Re: Disappointing packets-per-second performance results on a Dell, PE R530

2017-01-31 Thread Jordan Caraballo
This are the most recent stats. No advances so far. The system has -Current right now. Any help or feedback would be appreciated. Hardware Configuration: Dell PowerEdge R530 with 2 Intel(R) Xeon(R) E5­2695 CPU's, 18 cores per cpu. Equipped with a Chelsio T-580-CR dual port in an 8x slot. BIO

TCP_FASTOPEN is absent in GENERIC

2017-01-31 Thread Sergey Matveychuk
Hi. Is there a strong reason for option TCP_FASTOPEN is absent in GENERIC kernel? It's off by default anyway (net.inet.tcp.fastopen.enabled=0). Latest dns/bind* versions want it very much. ___ freebsd-net@freebsd.org mailing list https://lists.freebs

[Bug 213673] VNET + PF: enabling a firewall in a jail leaks memory

2017-01-31 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 Bjoern A. Zeeb changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org |b...@freebsd.org -- You are rece

[Bug 204340] [panic] nfsd, em, msix, fatal trap 9

2017-01-31 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 --- Comment #22 from Andriy Gapon --- (In reply to Rick Macklem from comment #20) Rick, thank you very much for the explanation! I knew that nfsd processes were special as they 'lend their stacks to kernel' or something like that. But I