[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 byt
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) |
Date: |
Sun, 19 Sep 2010 14:03:48 +0200 |
User-agent: |
Mutt/1.5.20 (2009-12-10) |
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
> > > <address@hidden> 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
- [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Stefan Hajnoczi, 2010/09/18
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Edgar E. Iglesias, 2010/09/18
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Kevin Wolf, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Edgar E. Iglesias, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Stefan Hajnoczi, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Michael S. Tsirkin, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Anthony Liguori, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Edgar E. Iglesias, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Michael S. Tsirkin, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Michael S. Tsirkin, 2010/09/20
- [Bug 638955] Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Edgar E. Iglesias, 2010/09/20
- Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes), Michael S. Tsirkin, 2010/09/21