From: Paolo Bonzini <pbonzini@redhat.com>
To: Fedorov Sergey <s.fedorov@samsung.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
aliguori@us.ibm.com, a.basov@samsung.com, qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] net/hub: remove can_receive handler
Date: Mon, 22 Apr 2013 18:09:03 +0200 [thread overview]
Message-ID: <5175609F.5030204@redhat.com> (raw)
In-Reply-To: <517556D9.2080809@samsung.com>
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
next prev parent reply other threads:[~2013-04-22 16:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 11:31 [Qemu-devel] [PATCH] net/hub: remove can_receive handler Sergey Fedorov
2013-04-22 11:47 ` Stefan Hajnoczi
2013-04-22 12:26 ` Fedorov Sergey
2013-04-22 14:57 ` Stefan Hajnoczi
2013-04-22 15:27 ` Fedorov Sergey
2013-04-22 16:09 ` Paolo Bonzini [this message]
2013-04-23 7:27 ` Fedorov Sergey
2013-04-23 6:58 ` Stefan Hajnoczi
2013-04-23 7:41 ` Fedorov Sergey
2013-04-23 12:00 ` Stefan Hajnoczi
2013-04-23 13:14 ` Fedorov Sergey
2013-10-21 11:44 ` Fedorov Sergey
2013-10-21 11:52 ` Fedorov Sergey
2013-10-28 7:26 ` Fedorov Sergey
2013-10-29 14:55 ` Stefan Hajnoczi
2013-10-30 10:29 ` Fedorov Sergey
2013-10-30 12:55 ` Stefan Hajnoczi
2013-04-23 9:32 ` Fedorov Sergey
2013-04-23 11:48 ` Stefan Hajnoczi
2013-04-23 11:58 ` Fedorov Sergey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5175609F.5030204@redhat.com \
--to=pbonzini@redhat.com \
--cc=a.basov@samsung.com \
--cc=aliguori@us.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=s.fedorov@samsung.com \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.