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:[EMAIL PROTECTED] > > Sent: Wednesday, March 05, 2008 12:12 AM > > To: [EMAIL PROTECTED] > > Cc: [email protected] > > 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. > > _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
