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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
