Re: [E1000-devel] e1000 driver is sending jumbo frames exceeding mtu

[Vik H. <vik...@ed...>]

OK. Problem solved, or at least a working workaround.

ethtool -K eth0 tso off

does it. It was my mistake to assume that tcpdump shows the =
representation of the ethernet frame that was about to go out on the =
wire. I now ran a tcpdump at the sending end and the receiving end. The =
sending end has datagrams exceeding 1500 bytes, and at the receiving end =
of the wire they are 1500 bytes or less. I think it is safe to assume my =
wires don't have the intelligence of assembling those packets :), so the =
Ethernet frames must indeed have been at most 1500+14 bytes at the =
sending side, corresponding the interfaces' set mtu of 1500.

I'm unaware of any method to determine the actual Ethernet frames length =
without hacking the code :(

#tc -s qdisc show dev eth0=20
(tso set to on)
|qdisc pfifo 11: parent 1:1 limit 1000p
| Sent 70493937 bytes 12899 pkt (dropped 0, overlimits 0 requeues 0)
| rate 0bit 0pps backlog 12112b 8p requeues 0

Note that this yields an avpkt of 5465 bytes, I would expect it to have =
been slightly less than 1500+14 bytes.

the e1000 device is a Intel Corporation 82541GI/PI Gigabit Ethernet =
Controller (rev 05) (lspci), the driver was originally the one from the =
FC5 updated kernel, but I have repeated the tests with your latest =
released "7.2.9-NAPI", with the same results.

With tc shaping to 10Mbit/s (using htb) with tso set to "on" on this =
e1000, I got a unstable throughput between 3.40MB/s and 3.80MB/s =
(measured using FTP download with ncftp client while downloading a 85MB =
file).

Repeating this with tso set to "off", now I get a very stable throughput =
of 1.13MB/s, which is about what I would expect it to be, maybe slightly =
less. Extra CPU utilization with this setting is beyond measurement =
small (load avg at the "e1000" server remains at 0.00/0.00/0.00 during =
the FTP download, indeed considering the wirespeed is only 100Mbps).

I'm going to try to have the tc guys gave a look at this. I've had a =
look at the shaping code of the kernel myself but it doesn't really make =
all sense to me :(
It would be nice that bandwidth limiting actually worked with tso set to =
on. As far as I know the tc guys don't count packets but bytes, but the =
must be something that goes horribly wrong there during those =
calculations (I haven't found a [if (size > mtu) size =3D mtu;] yet ;)

--=20
Vik Heyndrickx