qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v3 00/13] main-loop: Get rid of fd_read_poll and


From: Paolo Bonzini
Subject: Re: [Qemu-block] [PATCH v3 00/13] main-loop: Get rid of fd_read_poll and qemu_set_fd_handler2
Date: Wed, 20 May 2015 09:39:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 20/05/2015 08:38, Fam Zheng wrote:
> On Wed, 05/20 08:26, Paolo Bonzini wrote:
>>
>>
>> On 19/05/2015 17:02, Stefan Hajnoczi wrote:
>>> 1. Convert everything like you converted qemu-nbd.c.  This is a 
>>> conservative approach and we can be confident that behavior is 
>>> unchanged.
>>
>> So, that means whenever you change receive_disabled you call a new
>> callback on the peer?  In addition, whenever the count of
>> receive-disabled ports switches from zero to non-zero or vice versa,
>> hubs need to inform all its ports.
>>
>> There are just two places that set/clear receive_disabled,
>> qemu_deliver_packet and qemu_flush_or_purge_queued_packets, but I
>> think a new API is needed to implement the callback for hubs
>> (qemu_send_enable/qemu_send_disable).
> 
> I think .can_receive is the harder one, I'm not sure it's feasible - each
> device has its own set of conditions, so it will be a huge change.

The 1->0 transition is easy because it happens when message delivery
fails.  I know the network code very little, but I think queuing exactly
one packet in this case should be acceptable.  If this is true, the
network code can detect the 1->0 transition automatically.

The 0->1 transition should be easy in principle, because NICs are
supposed to call qemu_flush_queued_packets when it happens.  Not that
they do, but you can find some very old and partial work in branch
rx-flush of my github repo.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]