Igb driver, kernel vs intel

Hi!
There are already some threads about this....
Why is the kernel driver different?
For example, it doesn't support all module load options.
Like setting the interrupt rate, amount of queues...
?
Did someone try this Makefile?

That looks to be a lightly modified version of my Makefile that I created years ago.

I used out of tree igb drivers for a while, but stopped doing it as there wasn't any obvious advantage in return for needing to update (frequently unstable) versions regularly.

I don't know about recent out of tree driver versions, but some older releases were quite buggy and tended to spam the kernel log ring buffer with constant error messages.

Here I suggest you search for and read about in-tree vs out-of-tree drivers.

In tree drivers are part of the kernel source code, while out of tree drivers are typically published and maintained by the vendor. To generalise, they're often more "cutting edge" but also frequently more buggy as a result.

Well, this is kinda obvious?
The only difference I saw after a quick look is that the kernel driver doesn't support module load options.
Shame they stripped this for the kernel drivers.

If it's "kinda obvious" then why did you ask the question in the first place? You seem to have a habit of asking a question and then dissing the person who replies.

Well, sorry if it came across like this.
I asked why they are different and you explained the difference between them.
Maybe I should have phrased my question differently.
Why did Intel choose to remove some features of the kernel source tree drivers?

1 Like

I think around ~ 2 or 3 years ago, I was just googling for more tweaks to cake and came across this

https://lists.bufferbloat.net/pipermail/bloat/2020-August/015863.html

#dude trying to optimize for his situation

https://lists.bufferbloat.net/pipermail/bloat/2020-October/015928.html

1 month, later, a followup

https://lists.bufferbloat.net/pipermail/bloat/2020-November/016026.html
https://lists.bufferbloat.net/pipermail/bloat/2020-November/016037.html

then this final update caught my eye. He uses the IGB driver and claims increased performance!!!

I then went into another rabbit hole about RSS and forgot about this. So there might be benefits to the so called out of tree driver performance wise...

No problem.

I doubt Intel removed anything from the in tree drivers - they're just much older code. The out-of-tree drivers are the cutting edge ones that are undergoing active development and so are usually more up to date in terms of features.

Features from the OOT drivers eventually make their way into the in-tree drivers, but there's usually a (very) considerable lag.

Generally one wouldn't use the OOT drivers unless there's some very specific functionality you need that hasn't made it into the in tree version, since the trade-off is usually poorer stability / bugs and added maintenance needed to compile the OOT modules.

Please don't take this the wrong way, It's just my opinion on the general state of the development cycles that prematurely handicapping certain units.

Considerable lag meaning by the time those features are integrated, the device is close to end of life and far behind modern requirements. The point of "new" devices is to take advantage of modern features, not to purchase a unit to stored away in a box or handicapped.

I don't believe essential options like control over RSS Queues within the module at boot or Interrupt Moderation are considered "cutting edge". Why is the manual RSS Hash Key not supported in the driver? Things like including the kernel config, kernel boot time options for deciding the kernel hz, building with PREEMPT_VOLUNTARY instead of PREEMPT_NONE (It is literally a DESKTOP arch not just a tiny embedded device). I currently run voluntary, tickless, hz=1000 without any issues. The old fable about it won't improve response time, causes premature process interruption, won't improve sqm. Maybe on some tiny archs but not the big boys. More powerful platforms need to be TUNED as well to work more efficiently. There's no secret sauce or magical formula to this. It's universal and many other distros include this within their documentation. Racing sponsors don't enter stock cars to win races.

OpenWRT is a great platform with lots of support but the information and stigmas from many moons ago don't apply to today's demands. Otherwise, Linux as a whole wouldn't move forward. We got so many threads about to install a tube radio on an island with coffee cans and a string but meaningful threads are buried deep.

Overall we should just include the features and follow the usual disablement/stock settings but allow the user to configure outside those parameters instead of making them nonexistent. It's one thing to find out that a certain feature doesn't exist, it's another to find out the feature was purposely excluded.

Just my .50 cents (inflation happens)

I have them running for some time now.
They seem to work quite good.
While the upstream drivers default to max out the RSS queues the Intel Out-of-Tree drivers do not.
So modified the Makefile to set RSS=0 (sets queues = cores or maxes out the queues if cores > queues) by default, also disable EEE.
And set the build option to disable LRO,
because according to Intel's README this can cause issues when routing traffic.