Comment 9 for bug 638955

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
>> <email 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
>>
>