From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV0m0-0008V2-Mb for qemu-devel@nongnu.org; Thu, 17 May 2012 09:29:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SV0lt-0003dL-Ql for qemu-devel@nongnu.org; Thu, 17 May 2012 09:29:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV0lt-0003d7-JM for qemu-devel@nongnu.org; Thu, 17 May 2012 09:29:37 -0400 Message-ID: <4FB4FD3B.7070007@redhat.com> Date: Thu, 17 May 2012 15:29:31 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4F1EF6CE.9060306@gmail.com> <4F2F0038.3040209@redhat.com> <4FB4CA2D.4080501@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [QEMU] net: adapt dump to support the new syntax List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Yong Wu Cc: Stefan Hajnoczi , Benjamin , qemu-devel Il 17/05/2012 12:05, Zhi Yong Wu ha scritto: > On Thu, May 17, 2012 at 5:51 PM, Paolo Bonzini wrote: >>> This case has existed in current upstream code, not only vlan-hub >>> code. Currently can_send function has been called by backend send >>> function before deliver/deliver_iov, If we put can_send in queue send >>> function, your idea will have a big challenge for slirp packet queue. >> >> Exactly why? For SLIRP's receive path, SLIRP doesn't implement >> can_receive at all so it will never block. For the send path, when flow >> control kicks qemu_net_queue_append will copy the packet so it is not a >> problem for SLIRP's stack-allocated packets. > > You know that qemu_send_packet is void type, and has return value, if > can_send fails, if_encap will not currently get expected return value, > so this will cause that we have to modify the definition of > qemu_send_packet to make it return one valid value. a lot of functions > have called it, so i would not like to modify its definition. If qemu_can_send_packet returns false of course I would not drop the packet. I would append it to the queue (qemu_net_queue_append) for later processing. >>> We can implement your idea below later, not in this patchset. What do >>> you think? >> >> Note that my idea above was only means to an end. If you can remove the >> TODOs in a convincing manner, that would be fine. > You mean that we need adopt another handling way? or directly TODO comments? You need to address the TODOs. I proposed a way. It may actually not be correct, and there may of course be others. But the TODOs are there, and have to be solved. Paolo