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
