How do queue-less virtual devices wake higher level senders?
Subsystems (2)
Hello!
I am having some trouble figuring out how virtual interfaces (such as mac-vlans) can wake up writers (such as udp sockets).
For 'real' hardware, it seems that the netif_stop_queue and netif_wake_queue methods handle stopping and waking the higher level senders, but for virtual devices with no queues, how does this work?
In my case, I'm using a virtual Station interface that sits on top of a wifi radio interface (hacked up madwifi). I notice that UDP connections set up for high speed, unidirectional sends are stalling after a few minutes. netstat -an shows a write-buffer that is quite full, but nothing is transmitted.
If I ping or start any other type of traffic on these interfaces, the udp recovers. It seems like the udp send logic is just getting stuck and needs a kick.
I do not see any problems with TCP connections, and if I keep a slow-speed tcp connection running, the UDP will not hang.
It's likely the bug is in my driver and/or code, so this is not a bug report..just a question to hopefully help me debug it further :)
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
David Miller
maintainerFrom: Ben Greear <[email protected]>
Date: Mon, 01 Oct 2007 16:49:06 -0700
Quoted 4 lines
For 'real' hardware, it seems that the
netif_stop_queueandnetif_wake_queuemethods handle stopping and waking the higher level senders, but for virtual devices with no queues, how does this work?
They don't queue, there is nothing to stop or wakeup.
Quoted 9 lines · David Miller
From: Ben Greear <[email protected]>
Date: Mon, 01 Oct 2007 16:49:06 -0700Quoted 4 lines
For 'real' hardware, it seems that the
netif_stop_queueandnetif_wake_queuemethods handle stopping and waking the higher level senders, but for virtual devices with no queues, how does this work?They don't queue, there is nothing to stop or wakeup.
Ok, so if I have a UDP socket bound to an interface that has no queue, and yet I see the send portion of the queue being full in netstat, what does this mean?
Maybe the device I think has no queue somehow does?
I added some debugging to print out dev->state in sysfs, and the state of the virtual is always 0x6, which appears right to me. It's underlying device goes back and forth between 0x7 and 0x6, which also seems right to me.
When the thing is in the hung state, phys and virtual interface have 0x6 state, and yet the udp tx queue remains full. The physical NIC also prints out some errors about being low on buffers right before the hang, but it seems to recover since just doing a ping or starting a second udp connection brings everything back to life.
Other than IFF_UP and dev->state, are there other things that can make the tx logic stop sending to a device?
Thanks,
Ben
Quoted 4 lines
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
David Miller
maintainerFrom: Ben Greear <[email protected]>
Date: Mon, 01 Oct 2007 17:24:26 -0700
Quoted 9 lines
Quoted 8 lines · David Miller
From: Ben Greear <[email protected]>
Date: Mon, 01 Oct 2007 16:49:06 -0700Quoted 4 lines
For 'real' hardware, it seems that the
netif_stop_queueandnetif_wake_queuemethods handle stopping and waking the higher level senders, but for virtual devices with no queues, how does this work?
Quoted 5 lines
Quoted 1 line
They don't queue, there is nothing to stop or wakeup.
Ok, so if I have a UDP socket bound to an interface that has no queue, and yet I see the send portion of the queue being full in netstat, what does this mean?
The physical device sitting behind the virtual one is where queue stop and wakeup operations might be occuring.