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.

Make python a runtime dep and fix portversion derp

Move WANT_PGSQL up

Update order

I got the disjoint OPTIONS_DEFAULT ordering from Example 5.39 in https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html

I remember we tried to analyze and improve this and found some unintended consequences between @hiren and @lstewart https://reviews.freebsd.org/D8225 so it got backed out. @lstewart do you remember the details for backing it out?

We ran this configuration for a very long time at LLNW

I worked with rrs to suss out some bugs on this use case when it was new at job-1. I recently tested it to 40gbps single flow on my own pedestrian hardware (1st gen Xeon e3, ixl on one side chelsio T5 on the other) and the CPU usage didn't stand out to me. Yes there will be more timer soft interrupts but there are actually a lot of branching and date movement optimizations in the RACK stack that also help this single flow case. I'm not necessarily saying don't improve the default stack, just that it would probably be a good thing for your customers if you had the totality of the RACK stack improvements in there.

Are you aware of the RACK stack in /usr/src/sys/netinet/tcp_stacks/? It probably does everything you want

You may be able to add something to /usr/src/tests/sys/

Fixes https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215825

Will address in a version bump

I would prefer to see this bootstrapped and only for 12.0

Your PR patch looks good to me

This works for me and is the last qt4 application I had