Virtual device hdlc0 asks to que packet!

Virtual device hdlc0 asks to que packet!

[Russell McGuire]

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

Re: Virtual device hdlc0 asks to que packet!

[Joakim Tjernlund]

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.

RE: Virtual device hdlc0 asks to que packet!

[Russell McGuire]

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. 

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@transmode.se]
> Sent: Wednesday, March 05, 2008 12:12 AM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@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.

RE: 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@transmode.se]
> > Sent: Wednesday, March 05, 2008 12:12 AM
> > To: rmcguire@videopresence.com
> > Cc: linuxppc-embedded@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.
> 
> 

RE: Virtual device hdlc0 asks to que packet!

[Joakim Tjernlund]

On Wed, 2008-03-05 at 11:04 +0100, Joakim Tjernlund wrote:
> 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.

In 
  int mpc8360hdlc_register_netdev_ops(struct net_device *dev, dev_data_t *dev_data)
add	
   dev->tx_queue_len = 100;

 Jocke