Mark McLoughlin wrote:
It sucks that the kernel just silently truncates and doesn't give userspace a chance to retry with a larger buffer. We could add that as an extension, I guess.
What we want even more is to give the kernel a set of buffers (iovec) and have it fill them as much as it can with a number of packets, giving us some info as to where frames begin. Manage the whole thing using aio reads.
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.
Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
