about tx_queue_len for phonet driver

about tx_queue_len for phonet driver

[Hemant-vilas RAMDASI]

Hi,

Can anyone guide me about when should a network driver set tx_queue_len to 0?
We are facing a network congestion issue with phonet packets where one of the control message packet is dropped because of congestion. In our phonet network driver the tx_queue_len is set to 3 (taken from usb-phonet mostly). If phonet cannot handle packet-drop (for pipe messages), then should network driver always set tx_queue_len as 0?

Regards,
Hemant

Re: about tx_queue_len for phonet driver

[Eric Dumazet]

Le jeudi 12 janvier 2012 à 11:45 +0100, Hemant-vilas RAMDASI a écrit :
> Hi,
> 
> Can anyone guide me about when should a network driver set
> tx_queue_len to 0?
> We are facing a network congestion issue with phonet packets where one
> of the control message packet is dropped because of congestion. In our
> phonet network driver the tx_queue_len is set to 3 (taken from
> usb-phonet mostly). If phonet cannot handle packet-drop (for pipe
> messages), then should network driver always set tx_queue_len as 0?

0 is usually used by virtual devices, since real device has a queue.

In your case, I would rather increase a bit the tx_queue_len

I noticed in the past 3 is the default for ppp, and we can indeed have
drops because 3 is too small for current usages.

RE: about tx_queue_len for phonet driver

[Hemant-vilas RAMDASI]

> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Thursday, January 12, 2012 4:28 PM
> To: Hemant-vilas RAMDASI
> Cc: netdev@vger.kernel.org; Rémi Denis-Courmont
> Subject: Re: about tx_queue_len for phonet driver
> 
> Le jeudi 12 janvier 2012 à 11:45 +0100, Hemant-vilas RAMDASI a écrit :
> > Hi,
> >
> > Can anyone guide me about when should a network driver set
> > tx_queue_len to 0?
> > We are facing a network congestion issue with phonet packets where
> one
> > of the control message packet is dropped because of congestion. In
> our
> > phonet network driver the tx_queue_len is set to 3 (taken from
> > usb-phonet mostly). If phonet cannot handle packet-drop (for pipe
> > messages), then should network driver always set tx_queue_len as 0?
> 
> 0 is usually used by virtual devices, since real device has a queue.
> 
> In your case, I would rather increase a bit the tx_queue_len
> 
> I noticed in the past 3 is the default for ppp, and we can indeed have
> drops because 3 is too small for current usages.
> 
> 
What happens if it is set to 0? Is it something like infinite queue where packet is never dropped?
I see many drivers (mainly IPC) using 0. 

Thanks & Regards,
Hemant

Re: about tx_queue_len for phonet driver

[Rémi Denis-Courmont]

	Hello,

Le Jeudi 12 Janvier 2012 11:45:48 ext Hemant-vilas RAMDASI a écrit :
> Can anyone guide me about when should a network driver set tx_queue_len to
> 0? We are facing a network congestion issue with phonet packets where one
> of the control message packet is dropped because of congestion. In our
> phonet network driver the tx_queue_len is set to 3 (taken from usb-phonet
> mostly). If phonet cannot handle packet-drop (for pipe messages), then
> should network driver always set tx_queue_len as 0?

In theory, I guess the network device queuing discipline should be avoided 
altogether, unless there is another way to prevent packet loss, that I am not 
aware of. Unfortunately dropping qdisc, and thus net_device also, would have 
major redesign implications on the Linux Phonet infrastructure to say the 
least.

In any case, Phonet devices typically fail to provide sane, reliable and race-
free congestion control. I have seen some Phonet modem firmwares that just 
crash if they receive too many and/or too large packets. Alas, this cannot be 
fixed on the Linux / application processor side.


So you have to find a value large enough to avoid packet loss, but also small 
enough to avoid overflow and who-knows-what bugs on the modem side. For the 
record, the SSI driver queue length found on Nokia N9/N950 defaults to 100.

-- 
Rémi Denis-Courmont
http://www.remlab.net/