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

[Stefan Hajnoczi]

On Wed, May 20, 2015 at 8:39 AM, Paolo Bonzini <address@hidden> wrote:
> 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.

That's correct.  One packet is queued the first time
qemu_net_queue_send_iov() goes false.

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

That sounds good.  Failure to call qemu_flush_queued_packets is
already a problem today so this change would benefit some of the
existing NICs.

Stefan