[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MirageOS-devel] mirage-tcpip and jumbo frames
Heya,
I think so, MSS should track the underlying MTU, at least that's what a BSD network stack does. Ideally MSS is MTU - (all headers above tcp).
Sending a larger frame than the MTU from the tcp stack is bad, usually TCP should never rely on IP fragmentation and always max out a single datagram.
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?
Related to this, if the ethernet link actually has a small MTU, presumably TCP will emit large 1460 segments -- is this bad?
Cheers, Dave
[1] vpnkit uses the mirage-tcpip stack to terminate TCP flows (acting as a server) and proxies the data to/from regular Unix SOCK_STREAM/SOCK_DGRAM sockets: https://github.com/docker/vpnkit
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|