small correction:
On Sun, Jan 20, 2013 at 6:50 PM, Luigi Rizzo <ri...@iet.unipi.it> wrote:
> While running qemu 1.3.0 with the following network-related flags:
>
> -net nic -net tap,ifname=tap0,script=''
>
> I encountered the same problem (should be common to several
> frontends, e.g. e100, eepro100, virtio-net, xen_nic):
>
> in net/tap.c :: tap_send(), if qemu_send_packet_async() returns 0
> (e.g. because the NIC has no buffers available)
> traffic stops, despite the fact that the frontend will try to pull
> queued packets when the receive ring is updated.
>
> Upon investigation, it turns out that the backend code does
>
> size = qemu_send_packet_async(&s->nc, buf, size, tap_send_completed);
> if (size == 0) {
> tap_read_poll(s, 0);
>
> and the arguments are
>
> s->nc.name = "tap.0"
> s->nc.peer->name = "hub0port1"
> s->nc.send_queue = 0x7f40b2f61e20
> s->nc.peer->send_queue = 0x7f40b2f63690 <--- enqueued here
>
> whereis the frontend is trying to pull from a different queue
>
> qemu_flush_queued_packets(&s->nic->nc);
>
> with arguments
>
> s->nic->nc.name = "e1000.0"
> s->nic->nc.peer->name = "hub0port0" <--- try to flush this
> s->nic->nc.send_queue = 0x7f40b3008ae0
>
the queue that is actually flushed is s->nic->nc.send_queue or
0x7f40b3008ae0
s->nic->nc.peer->send_queue = 0x7f40b2f63660
>
>
> Note, regular traffic flows correctly across the hub,
> but qemu_flush_queued_packets() seems to try and pull
> from the wrong place.
>
> Any idea how to fix this (other than the inefficient solution
> of leaving read_poll=1 in the frontend)
>
> cheers
> luigi
>
cheers
luigi
--
-----------------------------------------+-------------------------------
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL +39-050-2211611 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-----------------------------------------+-------------------------------
