|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) |
Date: | Mon, 20 Sep 2010 15:31:32 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826 Lightning/1.0b1 Thunderbird/3.0.7 |
On 09/20/2010 05:42 AM, 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.QEMU never gets access to the wire. Our APIs do not really pass complete ethernet packets: we forward packets without checksum and padding. I think it makes complete sense to keep this and handle padding in devices because we have devices that pass the frame to guest without padding and checksum. It should be easy to replace padding code in devices that need it with some kind of macro.
Would this not also address the problem? It sounds like the root cause is the tap code, not the devices..
Regards, Anthony Liguori
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
0001-tap-make-sure-packets-are-at-least-40-bytes-long.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |