So I was doing a test-boot of 2.6.33.2 to see if my hang-on-suspend
Radeon DRM regression (fdo bug 26872) was cured (it wasn't), when a
new message appeared at bootup, the second of those below:
[ 8.766768] r8169: fastnet: link up
[ 8.791231] WARNING! Changing of MTU on this NICMay lead to frame reception errors!
(which appeared when I set the MTU on my r8169 to 7200.)
Not only is this message plainly misformatted :) but it does not explain
*why* changing the MTU is suddenly so bad, when it's worked forever
before now without flaw, with no sign of any sort of corruption. Why
should we be confined to non-jumbo frames? What are the effects if we
do change MTU?
The guilty patch appears to be a security fix, which strongly suggests
that 'frame reception errors' are not the only problem:
commit 8c96206544955131f6d7cef09371950f34ebca5a
Author: Neil Horman <nhorman@redhat.com>
Date: Mon Mar 29 13:16:02 2010 -0700
Now the warning message above does *not* say 'if you change the MTU you
bring a security problem back'. The commit message includes this
statement (here wrapped for column width):
2) This patch only disables frame filtering initially (i.e., during
the NIC open), changing the MTU results in ring buffer allocation of a
size in relation to the new mtu (along with a warning indicating that
this is dangerous).
Because of item (2), individuals who can't cope with the performance
hit (or can otherwise filter frames to prevent the bug), or who have
hardware they are sure is unaffected by this issue, can manually lower
the copybreak and reset the mtu such that performance is restored
easily.
Now this really should be in some documentation more easily accessible
than a git changelog, but even failing this... what performance hit? Are
we allocating 16K on every packet received, even if the packet is
smaller? If so, that doesn't strike me as being a *performance* problem
as much as a *reliability* problem, at least if this hardware ...
