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 <f...@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
