On Wed, May 20, 2015 at 8:39 AM, Paolo Bonzini <pbonz...@redhat.com> 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
