Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes)

["Michael S. Tsirkin" <mst@redhat.com>]

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
> > > <edgar.iglesias@gmail.com> 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