Merge branch 'fix-large-frames-in-the-gemini-ethernet-driver'
authorJakub Kicinski <kuba@kernel.org>
Tue, 14 Nov 2023 04:58:22 +0000 (20:58 -0800)
committerJakub Kicinski <kuba@kernel.org>
Tue, 14 Nov 2023 04:58:22 +0000 (20:58 -0800)
commit334e90b8d74f83b8cbe5c9b606d1690858b4897b
tree38d6cc86b3b1047de58ac138c7a725a6dc1f16d6
parent3cffa2ddc4d3fcf70cde361236f5a614f81a09b2
parentdc6c0bfbaa947dd7976e30e8c29b10c868b6fa42
Merge branch 'fix-large-frames-in-the-gemini-ethernet-driver'

Linus Walleij says:

====================
Fix large frames in the Gemini ethernet driver

This is the result of a bug hunt for a problem with the
RTL8366RB DSA switch leading me wrong all over the place.

I am indebted to Vladimir Oltean who as usual pointed
out where the real problem was, many thanks!

Tryig to actually use big ("jumbo") frames on this
hardware uncovered the real bugs. Then I tested it on
the DSA switch and it indeed fixes the issue.

To make sure it also works fine with big frames on
non-DSA devices I also copied a large video file over
scp to a device with maximum frame size, the data
was transported in large TCP packets ending up in
0x7ff sized frames using software checksumming at
~2.0 MB/s.

If I set down the MTU to the standard 1500 bytes so
that hardware checksumming is used, the scp transfer
of the same file was slightly lower, ~1.8-1.9 MB/s.

Despite this not being the best test it shows that
we can now stress the hardware with large frames
and that software checksum works fine.

v3: https://lore.kernel.org/r/20231107-gemini-largeframe-fix-v3-0-e3803c080b75@linaro.org
v2: https://lore.kernel.org/r/20231105-gemini-largeframe-fix-v2-0-cd3a5aa6c496@linaro.org
v1: https://lore.kernel.org/r/20231104-gemini-largeframe-fix-v1-0-9c5513f22f33@linaro.org
====================

Link: https://lore.kernel.org/r/20231109-gemini-largeframe-fix-v4-0-6e611528db08@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>