Virtual device hdlc0 asks to que packet!

[Joakim Tjernlund]

On Wed, 2008-03-05 at 00:43 -0800, Russell McGuire wrote:
> Jocke,
> 
> I wonder how one change this? I don't remember any of the API calls
> referencing this, so maybe the default to 1000? Or perhaps that is protocol
> specific. I will hunt through some of Freescale's Ethernet drivers and see
> if I can't find anything.

default is 1000 for ethernet.
See tx_queue_len in net/ethernet/eth.c, 
ether_setup(struct net_device *dev)

Maybe you can find out from there.

> 
> I know that inside the driver, I have 32 RX, and 32 TX buffers <buffer
> descriptors> available. There needs to be some smarter way to manage it
> though than raw numbers. Large file transfers, if they are cached, can
> easily over flow any number of buffers. 
> 
> Thanks for the note.
> 
> -Russ
> 
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> > Sent: Wednesday, March 05, 2008 12:12 AM
> > To: rmcguire at videopresence.com
> > Cc: linuxppc-embedded at ozlabs.org
> > Subject: Re: Virtual device hdlc0 asks to que packet!
> > 
> > 
> > On Tue, 2008-03-04 at 15:33 -0800, Russell McGuire wrote:
> > > All,
> > >
> > > Background MPC8360, using a T1 PHY as an HDLC device.
> > >
> > > Developing my hdlc driver, and was writing a simple send utility. To
> > test it
> > > out. Things seem well when I had massive delays in between the write()
> > or
> > > sendot(), and I was able to attain 100+Kbytes/sec. However, when I
> > replaced
> > > the simple usleeps(xxx) with select statements, suddenly I started
> > getting a
> > > ton of these messages.
> > >
> > > "Virtual device hdlc0 asks to que packet!"
> > >
> > > Along with dropped or non-sent data.
> > >
> > > In my driver I am tracking the available TX buffers, and issue a
> > > netif_stop_que() statement inside the start_xmit() call, with a
> > > corresponding netif_wake_que() in the tx_handler.
> > >
> > > Is there something else that needs to be done in order to make a select
> > > statement wait for the socket to not be busy? It seems that it always
> > > returns immediately with no timeout.
> > >
> > > I guess the other pieces of the scenario are as follows:
> > >
> > > * Using 'sethdlc hdlc0 hdlc' for the mode, so no IP stack is used.
> > > * Opening the socket to the hdlc device directly to the device itself,
> > i.e.
> > > no port number socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> > >
> > > I have used both sendto() and write() to pass data down, and they both
> > > return as if all the data has been sent, i.e. I never get an error.
> > >
> > > -Russ
> > 
> > When playing with your driver I noticed that the hdlc interfaces had
> > txqueuelen:0
> > Normal eth interfaces has txqueuelen:1000. Maybe you need to add a
> > txqueue to the hdlc interfaces?
> > 
> >  Jocke
> > 
> > PS.
> >     The driver seems to work now, I get both TX and RX IRQs now.
> 
>