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. On Thu, 19 Jan 2017 at 11:00, David Scott <[email protected]> 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? > > 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 > > [email protected] > > https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >
_______________________________________________ MirageOS-devel mailing list [email protected] https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
