|
From: | Luigi Rizzo |
Subject: | Re: [Qemu-devel] wrong argument to qemu_flush_queued_packets() in network frontends ? |
Date: | Sun, 20 Jan 2013 21:37:20 -0800 |
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
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
[Prev in Thread] | Current Thread | [Next in Thread] |