@gallatin I don't have the resources to fix it, so I'll just say of the things we were trying to do is get away from expert knob turning for common use cases, which I would lump a netapp filer and a CDN into for FreeBSD. iflib is supposed to not needlessly rearm interrupts while it is processing and there is no more work, so we should have some moderation of interrupts already or we need to add a callback into the framework so hardware like this can further modulate if necessary. I don't like bringing back a driver-only hack instead of holistically solving this. Nonetheless, if I am the only person that cares about that kind of thing I think my assumptions need to be retuned and I'll go away.
Tue, Nov 24
Mon, Nov 23
I would rather see this fixed by implementing LRO mbuf sorting in iflib, a la cxgbe and mlx5en. It's a small code change like https://freshbsd.org/commit/freebsd/src/317041. Would you be willing to look at this or discuss with intel to do it on your behalf?
Can you provide a justification in terms of performance and performance stability? This was dropped because it was believed to be unnecessary with the newer driver software queuing architecture.
Thu, Nov 19
My opinion is based on previous stack changes where there are 3 common cases I observed:
- A general improvement; ship it! Everyone benefits.
- A fatal error like connection drops or kernel panics; revert it! Since your internal testing has been performed, this kind of thing can still happen and it's ok to use HEAD to gather final testing and feedback, and back out if something was missed because it is unknown.
- A subtle performance issue but no impact to connectivity; fix it during the branching period or issue an EN. This doesn't necessarily fall onto you, for instance if it is a peculiar use case it might be an opportunity for someone else to diagnose and get exposed to the stack and help out. If it can be totally isolated with the sysctl, it is a very simple workaround for special cases.
@rscheff I'm not a fan of 13 shipping with this off if there are no known issues. The default stack is what most large and small freebsd send heavy users are on, and many larger commercial users are unaware of tuning parameters or the alternate stacks, so putting our best foot forward will help retain these users in the timeframe of 13.0. What do you think about toggling it on right before 13 branches, and it can be disabled if any PRs arise during the release process?
Tue, Nov 17
Thu, Nov 5
Oct 8 2020
Sep 30 2020
Sep 29 2020
Given the way things have gone, I'd like to see this in FreeBSD 13. I don't have the time to test and reason through sample streams with this change to give a formal approval, so consider this a concept ACK.
Sep 22 2020
Sep 21 2020
Sep 13 2020
Sep 11 2020
Aug 30 2020
Aug 28 2020
Aug 26 2020
Aug 22 2020
Aug 18 2020
One thing we do have is the full power8/9 pmcs in src/lib/libpmc/pmu-events/arch. I think these just need to be hooked up
Aug 10 2020
Aug 7 2020
Jul 28 2020
Jul 10 2020
May 13 2020
Having one other arch, arm64, compile seems like a reasonable litmus for the driver. I can look into the PPC stuff when AIC HW begins to appear on the market and it shouldn't block this.
May 12 2020
Can we enable this in an unsupported state for other 64-bit archs (arm64. ppc64)? Just would like to see the files entry correct for such usage.
@jhibbits just curious where are you reading ISA 3.1 info?
Apr 17 2020
Apr 14 2020
Apr 13 2020
This will be super useful for users, these overflow messages currently require a lot of system expertise to diagnose.
Mar 25 2020
As a slight detour is there any plan in place to get rid of !EARLY_AP_STARTUP? Stabilization is helpful here especially for MFC, but the number of test targets with EAPS and !EAPS made this code overwhelmingly fragile throughout its life.
Mar 21 2020
Feb 14 2020
Jan 26 2020
Yup I think there is room for additional improvement and discussion in later work but this part doesn't seem controversial to me. Linux has a more dynamic approach called quick ack which can drop down to 4ms, and the standard delack function can vary from 40ms up to 200ms.
Jan 23 2020
Is there some way to make the problem easy to reproduce like reducing descriptors?
Can you describe a bit what this is trying to address? This seems like a hopefully temporary condition that should be opted in by broken drivers, not default for every iflib driver.
Jan 21 2020
Jan 19 2020
Dec 8 2019
Dec 7 2019
Nov 29 2019
Nov 27 2019
Nov 26 2019
Nov 25 2019
Nov 23 2019
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241803 has done part of this
Nov 21 2019
Nov 14 2019
I see the updating entry was actually done on 20181211 so going to close this
@bcr thanks, btw do you think this is the right place to announce this kind of thing or should it be a package message?