From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qp6xv-0007gH-1A for qemu-devel@nongnu.org; Thu, 04 Aug 2011 19:04:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qp6xt-0006BF-ON for qemu-devel@nongnu.org; Thu, 04 Aug 2011 19:04:35 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:45752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qp6xt-0006B5-Hy for qemu-devel@nongnu.org; Thu, 04 Aug 2011 19:04:33 -0400 Received: by fxbb27 with SMTP id b27so684088fxb.4 for ; Thu, 04 Aug 2011 16:04:32 -0700 (PDT) Date: Fri, 5 Aug 2011 01:04:27 +0200 From: "Edgar E. Iglesias" Message-ID: <20110804230427.GC2601@zapo> References: <1309178511-20027-1-git-send-email-chouteau@adacore.com> <4E08925F.3030605@adacore.com> <4E08ABF4.1010206@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] Make SLIRP Ethernet packets size to 64 bytes minimum List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, Fabien Chouteau , mst@redhat.com On Tue, Jun 28, 2011 at 09:34:16AM +0100, Stefan Hajnoczi wrote: > On Mon, Jun 27, 2011 at 5:12 PM, Fabien Chouteau wrote: > > On 27/06/2011 17:39, Stefan Hajnoczi wrote: > >> On Mon, Jun 27, 2011 at 3:23 PM, Fabien Chouteau wrote: > >>> On 27/06/2011 15:50, Stefan Hajnoczi wrote: > >>>> On Mon, Jun 27, 2011 at 1:41 PM, Fabien Chouteau wrote: > >>>>> > >>>>> Signed-off-by: Fabien Chouteau > >>>>> --- > >>>>>  slirp/slirp.c |    4 ++-- > >>>>>  1 files changed, 2 insertions(+), 2 deletions(-) > >>>> > >>>> Any particular bug that this fixes? > >>>> > >>>> There have been 64 byte minimum padding patches to several emulated > >>>> NICs.  There has also been discussion about where the best place to do > >>>> this is.  Why is this patch necessary? > >>>> > >>> > >>> This patch is necessary because some NICs are configured to drop short frames, > >>> therefore the OS will not receive some of the packets generated by Qemu. > >>> > >>> There's a first patch to fix this issue: > >>> http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=dbf3c4b4baceb91eb64d09f787cbe92d65188813 > >>> > >>> My patch fixes two other sources of short frames. > >> > >> Thanks for the explanation.  I stepped back from the discussion on > >> where the right place to fix this is last time around.  Now I'm > >> wondering why do anything in slirp when the other sources (tap, ...) > >> aren't padding to 64 bytes? > > > > I think that packets generated by Qemu must follow RFC. For other sources, qemu > > should keep original size when possible and put padding otherwise. > > slirp interfaces to net.h which does not emulate Ethernet. For > example, it doesn't carry the Frame Check Sequence (FCS) as per the > Ethernet standard. NICs that want to report FCS to the guest > calculate it themselves, just like they do with 64-byte padding. So I > find it weird to say we should honor Ethernet when the transport we > are using is not Ethernet. > > This patch doesn't hurt but we'd be just as well off without it. > > Did you do this to fix a bug? If so, then something else in QEMU > needs to be fixed, not slirp. Hi, IMO SLIRP currently does claim to emulate Ethernet. Part of the problem is that QEMU's internal net router doesnt really route but acts more like a bridge between different networks. Different network wire formats dont get translated, they just pass through. To be able to emulate different network types, I think translation/routing will be necessary. Last time this came up, if I am not misstaken MST suggested that we add a translation macro or a function call to the netdevice models to be called when receiving packets that would translate into the desired wire format. I wasn't very happy about that because I didnt want to clutter the device models with stuff that the hw equivalence doesnt do but I dont have any better suggestions and I definitely think a receive call function to translate is better than the current state so thats what I would suggest now. MST, Im CC:ing you, please correct me if I remeber wrong. In the long run I think every netdevice should register the wire format is uses so that the core networking code can translate accordingly. That way we could support something injecting XXX talking to an Ethernet device. The internal format may very well be ethernet a la tap format, i.e ethernet without preamble, padding and CRC. Cheers