[Ecn-sane] fq_codel_fast with SCE and GSO/GRO splitting

[Ecn-sane] fq_codel_fast with SCE and GSO/GRO splitting

[Dave Taht]

I finished working up today my fork of fq_codel with both basic SCE
support and GSO/GRO splitting, that can be compiled easily out of
tree for a few more modern kernels (tested with 4.18)

I'm a little stuck in that I haven't been able to convince tc-adv to
configure it out of the same q_fq_codel.c that fq_codel uses (the API is
exactly the same, except that ce_threshold is now
sce_threshold). Anybody? I just figured i'd change the .id field.  Still
poking....

The fq_codel_fast project started because I wanted to balance my karma
after all the cpu cake ate up. I'd originally intended to simplify and
speed it up, then attempt to make a multicore shaper out of it... but
the SCE thing happened. I'd still like to do that at some point, but,
anyway:

* Out of tree build that doesn't have a lot of backport code yet
* Hard coded 1024 queues - so far nobody's needed more
* NO tc filter support - can't see a reason for it
* All the useless stats ripped out
* Bulk (on overload) dropper made closer to O(1)
* Bulk dropper feeds back into the codel count
* A mild revision to codel
* co-exists with fq_codel
* GSO/GRO support for ce_threshold > 0. Set it to a lot if you
  want to disable SCE. Set it to 0 for hopefully sped up normal
  fq_codel behavior.
  
I'm going to rip out packet limits as well in favor of a pure memory
limit.

I presently do not see a reason for a SCE ramp function, as
I don't intend to produce a configurable single or dual queue
version. If you want less or more queues, just recompile.....

I would like to measure the impact of the cpu scheduler on a wider
variety of low end hardware and see just how low the sce_threshold can
go, as well as how "bulky" reads off the rx ring currently are...

...after I figure out how to configure the darn thing and nail at least
one remaining bug.

Get it at: https://github.com/dtaht/fq_codel_fast

Patches gladly accepted!