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