@melifaro can you merge it? IMO this should be in the 13.0 ABI.

Thanks for doing this!

In D27666#629768, @mw wrote:

In D27666#629538, @emaste wrote:

In D27666#629463, @mw wrote:

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

Mainly I think we need to make a concerted effort towards identifying ports that require ELF feature tags to opt out of various features, and some common mechanism (either infrastructure or template approach) for setting those bits. I submitted PR252629

As above PR239873 reports issues with firefox and thunderbird with ASLR stack gap. I found libreoffice is incompatible with W^X and submitted PR252689 for that.

WRT ports do you see a better option than enable PIE/ASLR by default, let the community / port maintainers identify problems, create PR's and opt-out this option until fixed?

@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.

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.

My opinion is based on previous stack changes where there are 3 common cases I observed:

1. A general improvement; ship it! Everyone benefits.
2. 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.
3. 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?

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.

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

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.

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?

This will be super useful for users, these overflow messages currently require a lot of system expertise to diagnose.

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.

@krion @timur ping

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.

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.