From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49749 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxIiO-00022o-T0 for qemu-devel@nongnu.org; Sun, 19 Sep 2010 08:09:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OxIiN-0006Ay-Qb for qemu-devel@nongnu.org; Sun, 19 Sep 2010 08:09:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10417) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxIiN-0006Ab-KH for qemu-devel@nongnu.org; Sun, 19 Sep 2010 08:09:51 -0400 Date: Sun, 19 Sep 2010 14:03:48 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) Message-ID: <20100919120348.GI7350@redhat.com> References: <1284842625-13920-1-git-send-email-stefanha@linux.vnet.ibm.com> <20100918212710.GB3981@laped.lan> <20100919111801.GC7350@redhat.com> <20100919120455.GC3981@laped.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100919120455.GC3981@laped.lan> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: Stefan Hajnoczi , 638955@bugs.launchpad.net, Stefan Hajnoczi , qemu-devel@nongnu.org On Sun, Sep 19, 2010 at 02:04:55PM +0200, Edgar E. Iglesias wrote: > On Sun, Sep 19, 2010 at 01:18:01PM +0200, Michael S. Tsirkin wrote: > > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: > > > On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias > > > wrote: > > > > This doesn't look right. AFAIK, MAC's dont pad on receive. > > > > > > I agree. NICs that do padding will do it on transmit, not receive. > > > Anything coming in on the wire should already have the minimum length. > > > > > > In QEMU that isn't true today and that's why rtl8139, pcnet, and > > > ne2000 already do this same padding. This patch is the smallest > > > change to cover e1000. > > > > > > > IMO this kind of padding should somehow be done by the bridge that forwards > > > > packets into the qemu vlan (e.g slirp or the generic tap bridge). > > > > > > That should work and we can then drop the padding code from existing > > > NICs. I'll take a look. > > > > > > Stefan > > > > Not all nic devices have to be emulate ethernet, so not all devices want > > the padding, e.g. virtio does not. > > Right, ethernet behaviour should obviously not be applied unconditionally for > all net devices. > > > > It's also easy to imagine an > > ethernet device that strips the padding: would be silly to add it > > just to have it stripped. > > I dont beleive that is possible. The FCS comes last, so an ethernet MAC > would have to do really silly things to differentiate between padding and > real payload. > > > If we really want to do this generically, we could implement a function dealing > > with the padding, and call it from relevant devices. > > Another way is to have network devices register their link types so that the > generic bridge can apply whatever link specific fixups that may be needed. Well, we want to move away from using the generic bridge and to -netdev pairing of front/backend, anyway. Adding code there will just complicate that. > I would prefer to have the padding of bridged frames decoupled from the > device models, but I cant say I feel very strongly about this. > > Cheers