From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm: qemu: increase the size of the tap buffer [was Re: TAP MTU >= 4055 problem?] Date: Sun, 02 Nov 2008 16:32:45 +0200 Message-ID: <490DBA0D.1050705@redhat.com> References: <90eb1dc70810300729m5f2eeb3bg34784e554017d791@mail.gmail.com> <1225456125.3758.41.camel@blaa> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Faulkner , kvm@vger.kernel.org, Anthony Liguori To: Mark McLoughlin Return-path: Received: from mx2.redhat.com ([66.187.237.31]:47708 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753377AbYKBOcz (ORCPT ); Sun, 2 Nov 2008 09:32:55 -0500 In-Reply-To: <1225456125.3758.41.camel@blaa> Sender: kvm-owner@vger.kernel.org List-ID: 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