| commit | 1d45abc257d9b7ba9bb4b77a9bc6bc7b560d5cf6 | |
| author | Mark McLoughlin <markmc@redhat.com> | |
| Fri, 31 Oct 2008 12:28:45 +0000 (31 12:28 +0000) | ||
| committer | Avi Kivity <avi@redhat.com> | |
| Sun, 2 Nov 2008 14:27:10 +0000 (2 16:27 +0200) | ||
| tree | 6c65c88a2b4f77c57f92d13d19b187f56cacdff1 | treesnapshot (tar.gz zip) |
| parent | abd11aedadb8f7af11f15ec7ef42cc32c436f992 | commitdiff |
Increase size of tun/tap buffer
As debugged by Matthew Faulkner, with a 4k byte tap buffer if you
increase the MTU on the tap device to greater than 4k, the packets
read by qemu into the tap buffer will be truncated and the guest
will discard the packet.
With GSO enabled, we use a 64k tap buffer, so let's just use a 64k
buffer in all cases.
Also, remove the obtuse logic for figuring out the max GSO buffer
size. We shouldn't receive IP packets larger than 64k, so let's just
use 17 pages to make sure we've enough room for headers.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
As debugged by Matthew Faulkner, with a 4k byte tap buffer if you
increase the MTU on the tap device to greater than 4k, the packets
read by qemu into the tap buffer will be truncated and the guest
will discard the packet.
With GSO enabled, we use a 64k tap buffer, so let's just use a 64k
buffer in all cases.
Also, remove the obtuse logic for figuring out the max GSO buffer
size. We shouldn't receive IP packets larger than 64k, so let's just
use 17 pages to make sure we've enough room for headers.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
| vl.c | diffblobblamehistory |