From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuybQ-000597-GA for qemu-devel@nongnu.org; Wed, 20 May 2015 03:39:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YuybL-0003SB-9q for qemu-devel@nongnu.org; Wed, 20 May 2015 03:39:44 -0400 Sender: Paolo Bonzini Message-ID: <555C3A36.3060404@redhat.com> Date: Wed, 20 May 2015 09:39:34 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <20150520063803.GE6219@ad.nay.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Fam Zheng , Stefan Hajnoczi Cc: qemu-block@nongnu.org, Juan Quintela , Jason Wang , qemu-devel@nongnu.org, Vincenzo Maffione , "Vassili Karpov (malc)" , Gerd Hoffmann , Stefan Hajnoczi , Amit Shah , Giuseppe Lettieri , Luigi Rizzo 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