[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] mirage-tcpip and jumbo frames

  • To: David Scott <scott.dj@xxxxxxxxx>
  • From: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Thu, 19 Jan 2017 10:14:35 +0000
  • Cc: "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 19 Jan 2017 10:14:42 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=recoil.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=Hl2XrmaDcMkEC9DP+CmKrXqk/Buv3bFAQ+45eTK1pxHKHjtxHxy c8ACDfDbprd8H0IE+dYWmBP+8CSc0fCuqdAVt4bAgMccmBgmZc7GOK9gQytvPaSg j44Gfnh9Zm67X18aknseE8ZvxbEEgKaTs6nphLnOQMjNuXm/XwqiNflA=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

On 19 Jan 2017, at 10:00, David Scott <scott.dj@xxxxxxxxx> wrote:
> Hi,
> I'm trying to increase the performance a program which uses the mirage-tcpip 
> stack (specifically vpnkit[1] running on Windows). I noticed the total CPU 
> overhead in `top` was higher than I expected so I attempted to reduce the 
> overhead per byte by enabling jumbo frames. I bumped the MTU of the ethernet 
> link however this was not enough -- mirage-tcpip was still sending frames of 
> size ~1500 bytes. I tracked the problem down to the 
> [max_mss](https://github.com/mirage/mirage-tcpip/blob/756db428db2346a7b7461805cf233631b8f61a1e/lib/tcp/window.ml#L62)
>  -- when I manually bumped this and recompiled, I got larger frames and my 
> TCP throughput increased from 500Mbit/sec to 600Mbit/sec (there are other 
> overheads that also need addressing)
> So my questions is: how should this be done properly? Should the TCP layer 
> query the maximum IP datagram size (derived from the underlying ethernet 
> MTU)? Or is something more complicated needed?

That sounds right -- one missing feature is that we don't have Path MTU 
discovery in the stack, and so can only select on the basis of the immediate 
MTU (which may be larger than some intermediate hop, causing fragmentation on 
the wire).

Perhaps that's something (along with IPv6) for the Marrakesh hackathon?

> Related to this, if the ethernet link actually has a small MTU, presumably 
> TCP will emit large 1460 segments -- is this bad?

Yes, that's bad as it'll cause IP-level fragmentation, which we probably want 
to avoid -- I believe IPv4's minimum transmission unit is 68.

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.