From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuzN6-0006Sx-I3 for qemu-devel@nongnu.org; Wed, 20 May 2015 04:29:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YuzN5-00058J-Gy for qemu-devel@nongnu.org; Wed, 20 May 2015 04:29:00 -0400 MIME-Version: 1.0 In-Reply-To: <555C3A36.3060404@redhat.com> References: <1432032670-15124-1-git-send-email-famz@redhat.com> <20150519150238.GK9338@stefanha-thinkpad.redhat.com> <555C2917.2060101@redhat.com> <20150520063803.GE6219@ad.nay.redhat.com> <555C3A36.3060404@redhat.com> Date: Wed, 20 May 2015 09:28:58 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v3 00/13] main-loop: Get rid of fd_read_poll and qemu_set_fd_handler2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Fam Zheng , qemu block , Juan Quintela , Jason Wang , qemu-devel , Vincenzo Maffione , "Vassili Karpov (malc)" , Gerd Hoffmann , Stefan Hajnoczi , Amit Shah , Giuseppe Lettieri , Luigi Rizzo On Wed, May 20, 2015 at 8:39 AM, Paolo Bonzini 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