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.

Committed in rS355024

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241803 has done part of this

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?

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?)

Remove unneeded portrevision