- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 10 2019
Nov 6 2019
Nov 5 2019
Nov 4 2019
Nov 3 2019
Sep 19 2019
Sep 14 2019
This isn't worth much consternation but I do wonder if we can try to limit the proliferation of these sockopts. For instance, if you generalize the existing _LB to take a generic integer arg, would that and cpuset achieve the same effect (and generalize to however people want to use those numbered groups?)
Sep 12 2019
Sep 2 2019
Aug 4 2019
Jul 25 2019
Jul 24 2019
Remove unneeded portrevision
Jul 11 2019
Can these easily become per CPU counters instead? It seems like that would explain the performance loss, but per cpu should have hardly any overhead.
Jun 27 2019
Jun 26 2019
Jun 24 2019
Jun 14 2019
May 25 2019
I'll register strong desire to discard fragments immediately on interface vanishing. I don't expect that to come with any significant weight, my rational is whatever makes state management easier within current codebase and usage patterns of fbsd.
May 13 2019
Mar 23 2019
Mar 20 2019
Mar 19 2019
Mar 1 2019
Feb 28 2019
Feb 27 2019
Make python a runtime dep and fix portversion derp
Feb 26 2019
Feb 24 2019
Feb 17 2019
Feb 16 2019
Feb 15 2019
Feb 14 2019
Feb 13 2019
Move WANT_PGSQL up
Feb 10 2019
Feb 9 2019
Update order
I got the disjoint OPTIONS_DEFAULT ordering from Example 5.39 in https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html
Feb 6 2019
Feb 4 2019
Jan 31 2019
Jan 30 2019
Jan 24 2019
I remember we tried to analyze and improve this and found some unintended consequences between @hiren and @lstewart https://reviews.freebsd.org/D8225 so it got backed out. @lstewart do you remember the details for backing it out?
We ran this configuration for a very long time at LLNW
Jan 20 2019
Jan 19 2019
I worked with rrs to suss out some bugs on this use case when it was new at job-1. I recently tested it to 40gbps single flow on my own pedestrian hardware (1st gen Xeon e3, ixl on one side chelsio T5 on the other) and the CPU usage didn't stand out to me. Yes there will be more timer soft interrupts but there are actually a lot of branching and date movement optimizations in the RACK stack that also help this single flow case. I'm not necessarily saying don't improve the default stack, just that it would probably be a good thing for your customers if you had the totality of the RACK stack improvements in there.
Jan 18 2019
Are you aware of the RACK stack in /usr/src/sys/netinet/tcp_stacks/? It probably does everything you want
Jan 14 2019
Dec 30 2018
Dec 29 2018
You may be able to add something to /usr/src/tests/sys/