Re: kirkwood mv643xx_eth wrong tcp checksums
Lennert Buytenhek wrote on 23.11.2009 14:12:
> Kirkwood has a smaller transmit FIFO than other Orion chips, which
> means that hardware checksum offload doesn't work on jumbo frames.
Thanks for your fast answer. Your explanation seems logical to me. Is
the kirkwood's tx fifo limited to support only exactly 1500 bytes or do
you know if it is possible to use something like 4k jumbo frames?
Otherwise I could also try some different mtu sizes when I am at home
this evening. Maybe there is a trade-off somewhere between 1500 and 9000.
> 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?
Well, I must admit that I am not a "kernel hacker" but of course I could
test some patches. But if this would disable hardware checksums, do you
think that this would actually improve performance? Maybe the best
performance could be achieved by using the largest possible mtu which
can be processed by the hardware crc.
> I suppose this isn't using zero copy transmit, as I expected these
> numbers to be higher.
Hm, don't know. I used the default kernel and iperf that came with
debian squeeze (arm). On the other side it's a ubuntu file server (dual
core x64, 8 gb ram, intel server nic).
Did you mean that there might be no support for zero copy transmit in
the mv643xx_eth kernel module yet?
Reply to: