Re: [PATCH 5/5] Stop dropping so many RX packets in tap (v3)

[Anthony Liguori <aliguori@us.ibm.com>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Normally, tap always reads packets and simply lets the client drop 
>> them if it
>> cannot receive them.  For virtio-net, this results in massive packet 
>> loss and
>> about an 80% performance loss in TCP throughput.
>>
>> This patch modifies qemu_send_packet() to only deliver a packet to a 
>> VLAN
>> client if it doesn't have a fd_can_read method or the fd_can_read method
>> indicates that it can receive packets.  We also return a status of 
>> whether
>> any clients were able to receive the packet.
>>
>> If no clients were able to receive a packet, we buffer the packet 
>> until a
>> client indicates that it can receive packets again.
>>
>> This patch also modifies the tap code to only read from the tap fd if 
>> at least
>> one client on the VLAN is able to receive a packet.
>>
>> Finally, this patch changes the tap code to drain all possible 
>> packets from
>> the tap device when the tap fd is readable.
>>
>>  
>>  #if defined(CONFIG_SLIRP)
>> @@ -3970,6 +3976,8 @@ typedef struct TAPState {
>>      VLANClientState *vc;
>>      int fd;
>>      char down_script[1024];
>> +    char buf[4096];
>> +    int size;
>>  } TAPState;
>>   
>
> This breaks large MTUs.

They've always been broken for tap.

> How about the other way round: when the vlan consumer detects it can 
> no longer receive packets, it tells that to the vlan.  When all vlan 
> consumers can no longer receive, tell the producer to stop producing.  
> For the tap producer, this is simply removing its fd from the read 
> poll list.  When a vlan consumer becomes ready to receive again, it 
> tells the vlan, which tells the producers, which then install their 
> fds back again.

Yeah, that's a nice idea.   I'll think about it.  I don't know if it's 
really worth doing as an intermediate step though.  What I'd really like 
to do is have a vlan interface where consumers published all of their 
receive buffers.  Then there's no need for notifications of receive-ability.

Regards,

Anthony Liguori

> This is  a bit difficult since virtio and tap are both consumers and 
> producers, but could be made to work, I think.
>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone