How do queue-less virtual devices wake higher level senders?

How do queue-less virtual devices wake higher level senders?

[Ben Greear]

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: How do queue-less virtual devices wake higher level senders?

[David Miller]

From: Ben Greear <greearb@candelatech.com>
Date: Mon, 01 Oct 2007 16:49:06 -0700

> 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?

They don't queue, there is nothing to stop or wakeup.

Re: How do queue-less virtual devices wake higher level senders?

[Ben Greear]

David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Mon, 01 Oct 2007 16:49:06 -0700
> 
>> 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?
> 
> 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


> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: How do queue-less virtual devices wake higher level senders?

[David Miller]

From: Ben Greear <greearb@candelatech.com>
Date: Mon, 01 Oct 2007 17:24:26 -0700

> David Miller wrote:
> > From: Ben Greear <greearb@candelatech.com>
> > Date: Mon, 01 Oct 2007 16:49:06 -0700
> > 
> >> 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?
> > 
> > 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.