From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38113 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxcLN-0002vp-IK for qemu-devel@nongnu.org; Mon, 20 Sep 2010 05:07:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OxcKt-0005AU-2x for qemu-devel@nongnu.org; Mon, 20 Sep 2010 05:07:16 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:55963) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxcKs-00059x-Ux for qemu-devel@nongnu.org; Mon, 20 Sep 2010 05:06:55 -0400 Received: by fxm13 with SMTP id 13so612517fxm.4 for ; Mon, 20 Sep 2010 02:06:53 -0700 (PDT) Date: Mon, 20 Sep 2010 10:51:34 +0200 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) Message-ID: <20100920085134.GA618@edde.se.axis.com> References: <1284842625-13920-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C9527D1.4030707@reactos.org> <4C971E77.1000708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C971E77.1000708@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , "Michael S. Tsirkin" , Stefan Hajnoczi , qemu-devel@nongnu.org, =?iso-8859-1?Q?Herv=E9?= Poussineau , 638955@bugs.launchpad.net On Mon, Sep 20, 2010 at 10:42:31AM +0200, Kevin Wolf wrote: > Am 18.09.2010 23:12, schrieb Stefan Hajnoczi: > > On Sat, Sep 18, 2010 at 9:57 PM, Hervé Poussineau wrote: > >> Another patch creating ARP replies at least 64 bytes long has been > >> committed: > >> http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=dbf3c4b4baceb91eb64d09f787cbe92d65188813 > >> > >> Does it fix your issue? > > > > No I don't think so. This is an e1000 issue, it will happen if you > > use tap networking too. The commit you linked to only affects slirp > > and pads its ARP code. > > > > I think there are two places where the minimum frame length can be enforced: > > 1. The NIC emulation code. This is currently how rtl8139, pcnet, and > > ne2000 do it. My patch adds the same for e1000. > > 2. The net layer. If we're emulating Ethernet then it would be > > possible to pad to minimum frame length in common networking code > > (net.c). > > 3. The sender. I think it should be the sender's decision which packet > he sends and there's no reason to manipulate it on its way to the guest. > If the sender sends too short packets, this is where the bug is. Yes, but when using tap, the ethernet sender is QEMU itself. Tap doesn't have the same requirements as ethernet so the original sender has no reason to pad. Internally in QEMU, there is code that picks up tap packets and forwards them to the emulated ethernet links, this is were padding should be done IMO. Not in the device models receive path. The bridge that forwards frames from tap into emulated links must also handle different kinds of link types, as all emulated network devices are not necessarily ethernet. Cheers