Re: kirkwood mv643xx_eth wrong tcp checksums
On Mon, Nov 23, 2009 at 02:08:22PM +0100, David Fröhlich wrote:
> Hi,
Hi,
> I have a QNAP TS-119 device and flashed debian squeeze on it as
> described on this website:
> http://www.cyrius.com/debian/kirkwood/qnap/ts-219/install.html
> Thanks a lot for this great debian port. It's nice to have such a
> powerful nas running with a native debian system.
>
> But I am unable to use jumbo frames with the mv643xx_eth kernel module.
> My network supports jumbo frames and I had no problems in using jumbo
> frames on the previously installed qnap os.
>
> If I now enable jumbo frames (ifconfig eth0 mtu 9000) all outgoing
> ethernet frames which are larger than 1500 bytes have incorrect tcp
> checksums and are discarded by the other hosts. I captured it with
> wireshark and frames <= 1500 bytes all have a correct checksum. It is
> also a bit strange that frames > 1500 byte all have the same tcp
> checksum 0x81d5.
>
> I gues that there is something going wrong with the tcp checksum
> (offload?) engine.
>
> Are there any known problems concerning jumbo frames and/or tcp checksums?
Kirkwood has a smaller transmit FIFO than other Orion chips, which
means that hardware checksum offload doesn't work on jumbo frames.
What should be done is that the ARM platform code should pass the
maximum hardware checksummable packet size into the mv643xx_eth via
the platform data, and mv643xx_eth should check that against the
skb length and fall into the skb_checksum_help() path if the packet
is too long.
I got a patch for this at some point from someone, but I seem to
have lost it. Feel like giving it a try?
> root@server:~# iperf -c nas.lan.froehlich.ws -N
> ------------------------------------------------------------
> Client connecting to nas.lan.froehlich.ws, TCP port 5001
> TCP window size: 640 KByte (default)
> ------------------------------------------------------------
> [ 3] local 172.24.0.71 port 36931 connected with 172.24.0.70 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.0 sec 447 MBytes 375 Mbits/sec
I suppose this isn't using zero copy transmit, as I expected these
numbers to be higher.
thanks,
Lennert
Reply to: