diff options
author | Bhasker Hariharan <bhaskerh@google.com> | 2020-07-30 14:44:34 -0700 |
---|---|---|
committer | gVisor bot <gvisor-bot@google.com> | 2020-07-30 14:46:49 -0700 |
commit | f15d5a8d0fe4ad7d072909e7957977756f7be118 (patch) | |
tree | 4c245840b8d849ceac12e3d6fd216c388b7de885 /pkg/tcpip/link/sharedmem | |
parent | 9960a816a9ad65a4a6620eee5a66e5cc071b60cb (diff) |
Revert change to default buffer size.
In
https://github.com/google/gvisor/commit/ca6bded95dbce07f9683904b4b768dfc2d4a09b2
we reduced the default buffer size to 32KB. This mostly works fine except at
high throughput where we hit zero window very quickly and the TCP receive
buffer moderation is not able to grow the window. This can be seen in the
benchmarks where with a 32KB buffer and 100 connections downloading a 10MB
file we get about 30 requests/s vs the 1MB buffer gives us about 53 requests/s.
A proper fix requires a few changes to when we send a zero window as well as
when we decide to send a zero window update. Today we consider available space
below 1MSS as zero and send an update when it crosses 1MSS of available space.
This is way too low and results in the window staying very small once we hit
a zero window condition as we keep sending updates with size barely over 1MSS.
Linux and BSD are smarter about this and use different thresholds. We should
separately update our logic to match linux or BSD so that we don't send
window updates that are really tiny or wait until we drop below 1MSS to
advertise a zero window.
PiperOrigin-RevId: 324087019
Diffstat (limited to 'pkg/tcpip/link/sharedmem')
0 files changed, 0 insertions, 0 deletions