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.igles...@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
