- User Since
- Jun 6 2015, 10:46 PM (136 w, 5 d)
Mon, Jan 15
Tue, Jan 9
Wed, Jan 3
Thu, Dec 28
Wed, Dec 27
Thanks, your changes worked
Sun, Dec 24
Sat, Dec 23
Nov 27 2017
Nov 13 2017
@oliver out of curiosity can you boot it with a KERNCONF with options MAXCPU=12
Oct 26 2017
Oct 8 2017
It LGTM. I know sfbufs are quite different on i386, do you need anyone to do some basic tests there?
Sep 26 2017
Sep 25 2017
Sep 21 2017
Freenode #ppc64 if you want to go direct, a lot of the firmware and kernel team are there
I'm just relaying a conversation :)
Some advice from an IBM firmware team member:
[22:51] <segher> ah ok. some review... don't use endian-swapping macros; use a macro to do the actual memory accesses in the endian you want, instead
[22:52] <segher> and yup, very cool to see some other os on p8 :-)
Sep 11 2017
This is silly to bikeshed. 12.0 wont be released for at least a year and -CURRENT is for API breaks. Users can run the current -STABLE trees in a jail if they have any shitware they need to support for a long time. It's also trivial to maintain the patch in a corporate tree if needed, or a compat lib that doesn't live in src/.
Sep 6 2017
Sep 4 2017
And by that I mean we should use random_harvest_fast
I prefer the solution in https://reviews.freebsd.org/D12132, and provide commentary in there as to why we shouldn't grow a wart in iflib for what I believe are misunderstandings on entropy collection that occurred when Fortuna went in.
@markm are you able to provide guidance on this or may we proceed in running the performance issues to ground?
Aug 29 2017
The random situation has been bugging me since Fortuna went in, the default mask is WAY too aggressive. Schneier himself says "Slowing down the prng by a perceptible factor to get a few bits more security is counterproductive" in his article describing it. I think the right choice is to always use random_harvest_fast in the network paths.
Aug 28 2017
Aug 23 2017
Aug 14 2017
Noob question, should freebsdversion bump since this alters the ABI?
Use the libxo plurals and fix the pmtud-failed label
Aug 12 2017
Aug 11 2017
Jul 27 2017
Jul 25 2017
To document my understanding.. this is safe because interrupts are disabled while handling rx, including passing work to the 'que_task' if processing limits are present.
Jul 24 2017
Jul 21 2017
@sepherosa_gmail.com does this look good to you now?
Jun 28 2017
Jun 16 2017
Jun 12 2017
Jun 10 2017
Ok, sounds like it's not the time to have that discussion since we don't yet really know how the other stacks will compose.
Jun 9 2017
Should tcp_default.c move under tcp_stacks/default.c?
Jun 7 2017
Sorry wrong repo in last comment, here's the one https://github.com/openzfs/openzfs
This will need to be a github pull request against https://github.com/illumos/illumos-gate
May 31 2017
May 26 2017
@kmacy is this still relevant?
May 25 2017
@lstewart our staff transport committer has moved on, would you be willing to commit this to HEAD for Matt?
Apr 27 2017
I don't have the credibility to slow anything down, I'll table the broader discussion for BSDCan dev summit.
I'm not sure I fully understand this, but my reading is that it moves intr threads that are typically round-robin distributed once during boot/attach around at runtime at 1Hz? I do have some concerns if that is the case, particularly for networking. We rely heavily on prefetching data, so intr movement and intr preemption are both bad IMO (but to what extent is actual research, and should include generic scheduling policy). An overarching concern of mine is keeping things (locks and data) vertically aligned on a core between layers.. from tx/rx intrs up through transport layer and application (via RSS). There are things in motion that seem to move away rather than toward that goal.
Apr 5 2017
Mar 24 2017
I think this review supersedes D5213, if there are other diffs they should be added here. Matt approved the change proposed by @krzysztof.galazka_intel.com https://github.com/mattmacy/networking/pull/5
Mar 23 2017
I would like to see this integrated soon, @sbruno has gotten iflib.c leveled up to a good spot and we are running it in production for e1000. @jeffrey.e.pieper_intel.com are you ok with @cramerj_intel.com latest fixes?
Mar 20 2017
Mar 19 2017
To clarify for @sbruno this isn't related to iflib or the issues we had there, just doing a thing while I'm in sparc64.
Feb 24 2017
I think that is a good call, 10 is pretty long in the tooth these days.
Jan 16 2017
This needs to be resynced against ports updates. I can do so if desired.
Jan 13 2017
Use sbused accessor per BZ
Jan 12 2017
Updated to use sb_ccc. Add diff context
Dec 9 2016
I found Microsoft's docs quite good https://msdn.microsoft.com/en-us/windows/hardware/drivers/network/offloading-the-segmentation-of-large-tcp-packets.
Nov 16 2016
Oct 19 2016
Just to follow up publicly with my own testing results, we've addressed all known issues and the performance and queue distribution look very good on a production Internet facing system.
Oct 12 2016
Oct 10 2016
Matt approved in LLNW IRC
Oct 9 2016
@sbruno I can't update the diff myself, can you please apply https://gist.github.com/kev009/4e464d396782c677ef5a6e7ff61bfc9b on top of the latest rev?
Oct 8 2016
Oct 6 2016
Oct 5 2016
Oct 4 2016
Oct 3 2016
As far as I can tell this is good. I have a box serving large volume of internet facing traffic with a data accept filter.
Sep 29 2016
Sep 23 2016
Sep 21 2016
@gnn I heard there was some news on the FF front, can we import this to vendor?
Aug 31 2016
Jul 14 2016
Jun 26 2016
Address Andriy's comment on accidentally removing rS299883.
It seems to go through 2 watchdog resets on boot while scanning/associating, then is fairly reliable. I've now passed a few gigabytes over the 8260 w/o hiccups.