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

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.

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.