From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUXdU-0008PY-6x for qemu-devel@nongnu.org; Tue, 23 Apr 2013 03:27:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUXdS-00053M-HL for qemu-devel@nongnu.org; Tue, 23 Apr 2013 03:27:32 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:38223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUXdS-00052x-Az for qemu-devel@nongnu.org; Tue, 23 Apr 2013 03:27:30 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MLP00FXL5U8RL50@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 23 Apr 2013 08:27:27 +0100 (BST) Message-id: <517637DD.1040107@samsung.com> Date: Tue, 23 Apr 2013 11:27:25 +0400 From: Fedorov Sergey MIME-version: 1.0 References: <1366284715-10107-1-git-send-email-s.fedorov@samsung.com> <20130422114711.GA21317@stefanha-thinkpad.redhat.com> <51752C68.6030408@samsung.com> <20130422145749.GA28049@stefanha-thinkpad.redhat.com> <517556D9.2080809@samsung.com> <5175609F.5030204@redhat.com> In-reply-to: <5175609F.5030204@redhat.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] net/hub: remove can_receive handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , aliguori@us.ibm.com, a.basov@samsung.com, qemu-devel@nongnu.org, Stefan Hajnoczi On 04/22/2013 08:09 PM, Paolo Bonzini wrote: > Il 22/04/2013 17:27, Fedorov Sergey ha scritto: >> E.g. network hub has 3 ports. Suppose when iterating through port list >> in net_hub_port_can_receive() a packet is successfully delivered to the >> first port, and then is queued in the source port queue because the >> second port cannot receive packets. Later net_hub_flush() will flush the >> packet from the source port queue and it will be delivered in every >> port. But it had been already delivered to one of them. So it will be >> delivered twice to some ports. Moreover there is less chance to dequeue >> the packet if several clients can't receive periodically. > Perhaps it is indeed wrong to do this blocking in can_receive()... > You're right that a hubport can always receive, but the hub itself > should have a queue. If one port cannot receive, the packet should be > appended to the hub's queue. And net_hub_flush will just go through the > hub's queue. > >> Anyway, actually there is no need in net_hub_port_can_receive() as the >> network hub can always receive packets and pass it to its port network >> clients with qemu_send_packet(). I think it's more natural solution. > I think the point was to keep dumps in sync with what actually happened > on the other ports. Otherwise a "-net dump" port will show the packet > immediately, even though it hasn't been delivered yet. > > Paolo > The user documentation says that `-net dump' dumps network traffic on VLAN. There is nothing said about interfaces connected to VALN nor synchronization with them. In my view, VLAN hub is a device that forwards an incoming packet to all other ports as soon as possible, just like real hardware hub. I think of `-net dump' as a special network interface that dumps every packet received by VLAN hub itself, not delivered to its clients. If we want to dump packets actually delivered to network interfaces we need to do it in per-interface manner. Maybe I misunderstand? -- Best regards, Sergey Fedorov, Junior Software Engineer, Samsung R&D Institute Rus. E-mail: s.fedorov@samsung.com