Why the Eth0's driver cost CPU so much?

If trying to download a big file through eth0, there will be a ksoftirq/0 thread , its cpu usage is about 60%(on one cpu node), and the total cpu usage is about 30%. but I have a old TX2 module which can run the R27.1, the total usage is only 5% when execute the same task. does it mean that the ethernet controller hardware in new TX2 module is downgraded? thanks.

Not an answer, but perhaps some useful information on the topic…someone else will still have to answer.

The kernel drivers have basically two kinds of driver software: Either software which the hardware directly depends on, or software which can be split away from the hardware and run separately. The first kind of software only runs when talking to the hardware, the latter type can migrate to different CPU cores or run after the hardware itself is detached. The ksoftirq is the latter.

Good design implies that a CPU core is locked only for the minimal amount of time by hardware talking to drivers. The ksoftirq component is not actually talking to hardware. It is possible that if certain operations were done in hardware (some sort of acceleration) in one design, but then the hardware changed to no longer have the acceleration, that the load would go up and show up in ksoftirq. I don’t really know if this is the case for you, but it is very hard to say without knowing not only about the original test case of R27.1, but also what the current version is (see “head -n 1 /etc/nv_tegra_release”).

The higher load in ksoftirq could also relate to changes in how kernel driver components work together. Sometimes one driver might depend on another, e.g., if we were using bulk storage with and without encryption, then we might see ksoftirq go up for the results of bulk storage talking to encryption software. There is a similar possibility with ethernet. What you are seeing might be a result of rearranged driver layout based on other drivers and not necessarily due to the ethernet itself. Any changes to networking parameters, e.g., jumbo packets, might change the load on the ksoftirq part of the CPU load.

For someone to truly give you an answer, if they have not already seen the issue before, you would likely need to give a simple test case of how to reproduce this. Then it might be possible to trace what it is that changes (and you would need to give the L4T release version as well…newer releases have probably rearranged kernel layout).