From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52973 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxIdh-0000kT-Qq for qemu-devel@nongnu.org; Sun, 19 Sep 2010 08:05:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OxIdf-0005Iy-RD for qemu-devel@nongnu.org; Sun, 19 Sep 2010 08:05:01 -0400 Received: from mail-ey0-f173.google.com ([209.85.215.173]:56167) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxIdf-0005Il-Mq for qemu-devel@nongnu.org; Sun, 19 Sep 2010 08:04:59 -0400 Received: by eyf18 with SMTP id 18so1696294eyf.4 for ; Sun, 19 Sep 2010 05:04:58 -0700 (PDT) Date: Sun, 19 Sep 2010 14:04:55 +0200 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) Message-ID: <20100919120455.GC3981@laped.lan> References: <1284842625-13920-1-git-send-email-stefanha@linux.vnet.ibm.com> <20100918212710.GB3981@laped.lan> <20100919111801.GC7350@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100919111801.GC7350@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Stefan Hajnoczi , 638955@bugs.launchpad.net, Stefan Hajnoczi , qemu-devel@nongnu.org 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. 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