Re: kirkwood mv643xx_eth wrong tcp checksums
On Mon, Nov 23, 2009 at 02:33:42PM +0100, David Fröhlich wrote:
> > 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?
I think the FIFO is around 2K, but I'm not exactly sure. I'd have
to do some tests.
> > 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.
No matter which MTU the user/admin sets, the hardware/driver should
just work. I.e. packets should always go out with correct checksums.
Which MTU is optimal is a different issue. And yes, it's certainly
possible that MTU 9000 with software checksums will be slower than
MTU 1500 with hardware checksums.
> > 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?
There is, but I'm guessing (I've never used iperf myself) that you
need to set some option to make it use zero-copy transmit.
Regular transmit (with one user->kernel copy) is done with the
system calls write(2), send(2), sendto(2) or sendmsg(2), while for
zero-copy transmit, either sendfile(2) or splice(2) needs to be
used.
You can probably figure out which method iperf is using by
strace'ing it, and seeing which of the above system calls it uses
to put data in the socket's transmit queue.
thanks,
Lennert
Reply to: