Make MTU configurable and implement TCP MSS

[ading2210]

This PR makes the MTU configurable in the v86 TCP/IP stack and the virtio NIC. It also implements the TCP maximum segment size option (MSS).

The MTU can be set to 65535 bytes, which leads to a massive speed improvement. I was able to get 400mbit/s download speeds and 230mbit/s upload speeds inside the guest VM while using Wisp networking.

Implementing the TCP MSS option allows the guest to send the maximum sized TCP payloads for the configured MTU (MTU - 40 bytes). Previously, the MSS option would not be specified by the v86 TCP stack, so the guest would fall back to sending 536 byte TCP payloads (as required by the TCP spec).

I've tested it to work well with the Wisp, fetch, and wsproxy network backends.

I then added an option to the frontend to specify the NIC type and MTU.

Also included in the PR is a fix for a bug in the Wisp network adapter that would cause a crash if the Wisp stream started buffering during uploads.

---

As a result of these changes, the network is now fast enough to facilitate hardware accelerated OpenGL in the guest via VirGL over TCP:

8mb.video-REt-sa4Ba3iS.mp4

I posted more details about that here: #51 (comment)

[basicer]

Very nice! It's awesome how far we have come on this since the wsproxy days.

[copy]

The code looks good to me, could one of @basicer, @ProgrammerIn-wonderland or @chschnell do a quick review on this?

[ProgrammerIn-wonderland]

Code looks fine, I'll compile to test it tonight

[chschnell]

Using Jumbo frames with virtio is a great idea!

However, I can't reproduce the results, clearly I'm doing something wrong here.

I'm using wsnic as the relay which supports MTUs of up to 16K (I had assumed a max. MTU of the commonly used 9000 when I wrote it), but that could of course be raised to any value.

As I've done in the past, I tested iperf and curl with guest OS v86-buildroot but with MTUs of 1500 and 9000, and both came out with very similar results (iperf with around 200 Mbits/sec and curl with around 40000 kB/sec). I couldn't really tell a difference.

My guess is that it's something about wsinc or buildroot, I'll run more tests tomorrow.

@ading2210: Which guest OS did you use? Do you have any tips for me? And please fix the eslint errors :)

Console output of iperf and NIC setup (note the mtu 9000):

~% iperf -c 192.168.86.1
------------------------------------------------------------
Client connecting to 192.168.86.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  1] local 192.168.86.21 port 54032 connected with 192.168.86.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  1] 0.00-10.05 sec   237 MBytes   198 Mbits/sec
~% ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000
    link/ether 00:22:15:dd:22:9f brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.21/24 brd 192.168.86.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::222:15ff:fedd:229f/64 scope link 
       valid_lft forever preferred_lft forever

[ading2210]

@chschnell I used an Alpine Linux guest. I uploaded my disk image here so you can try with that one: https://local.ading.dev/array/alpine_hda.zip

I don't think there would be much of a performance improvement with a higher MTU on the older wsproxy network transports, especially if your proxy server is on localhost. That bypasses the v86 virtual TCP/IP stack entirely, so most of the changes in this PR don't have any effect. Try testing with Wisp networking instead.

[ProgrammerIn-wonderland]

Also the wisp.mercurywork.shop is bandwidth limited so you probably want to use wisps://anura.pro/

[basicer]

LGTM

[copy]

Thanks all!