Re: [Qemu-devel] (no subject)

[Fam Zheng <famz@redhat.com>]

On Tue, 06/30 00:49, Scott Feldman wrote:
> Hi Fam, Stefan,
> 
> I'm running a test with rocker device using UDP sockets connections
> and I'm seeing the socket s->read_poll stay disabled if the device
> receives a packet when the device's can_receive returns false.
> Receive is stuck after that; nothing ever re-enables s->read_poll.  I
> see the first packet queued on queue->packets and that's it.   No more
> receives.  If I modify the device to lie and always return
> can_receive=true, and drop the pkt in driver receive, then things work
> fine.
> 
> I think this patch broke can_receive semantics for net/socket.c:

Yes. The semantics now is if .can_receive returns false, the NIC needs to flush
the queue explicitly when the conditions in .can_receive become true, because
net/{socket,tap,...} no longer polls .can_receive().
> 
> commit 6e99c631f116221d169ea53953d91b8aa74d297a
> Author: Fam Zheng <famz@redhat.com>
> Date:   Thu Jun 4 14:45:16 2015 +0800
> 
>     net/socket: Drop net_socket_can_send
> 
> Anything jump out?
> 
> (In the test, rocker device is enabling the netdev port once the guest
> OS driver signals to enable the port based on STP process running on
> the guest.  The initial STP state is DISABLED, so the port is isolated
> from the network.  As STP algo progresses, the port is opened up and
> the netdev is enabled for Rx traffic).
> 
> -scott
> 

Does dropping .can_receive or forcing 1 work for you? Or maybe something like
this:

diff --git a/hw/net/rocker/rocker_fp.c b/hw/net/rocker/rocker_fp.c
index d8d934c..3209ccd 100644
--- a/hw/net/rocker/rocker_fp.c
+++ b/hw/net/rocker/rocker_fp.c
@@ -203,6 +203,7 @@ void fp_port_enable(FpPort *port)
     fp_port_set_link(port, true);
     port->enabled = true;
     DPRINTF("port %d enabled\n", port->index);
+    qemu_flush_queued_packets(qemu_get_queue(port->nic));
 }
 
 void fp_port_disable(FpPort *port)

---

Fam