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