> IMHO this scenario occurs so infrequently that the check
> isn't worth it especially since the driver has to be able to
> deal with us calling it after netif_stop_queue() anyway.
That sounds just fine to me. Thanks Krishna and Herbert for weighing in
on this.
-PJ Waskiewicz
-
To unsubscribe
On Wed, Jun 13, 2007 at 10:51:00AM -0700, Waskiewicz Jr, Peter P wrote:
>
> I somewhat disagree here. The underlying driver can conceivably stop
> the device queue even if the stack holds the queue lock during an
> interrupt to clean Tx descriptors, and it finds it's out of them or
> needs to gra
On Wed, Jun 13, 2007 at 02:10:49PM +0530, Krishna Kumar wrote:
>
> - BUG_ON((int) q->q.qlen < 0) was a relic from old times when -1
> meant more packets are available, and __qdisc_run used to loop
> when qdisc_restart() returned -1. During those days, it was
> necessary to make sure that qle
Hi Peter,
Thanks for your feedback.
> > - netif_queue_stopped need not be called inside qdisc_restart as
> > it has been called already in qdisc_run() before the first skb
> > is sent, and in __qdisc_run() after each intermediate skb is
> > sent (note : we are the only sender, so the queue
> - netif_queue_stopped need not be called inside qdisc_restart as
> it has been called already in qdisc_run() before the first skb
> is sent, and in __qdisc_run() after each intermediate skb is
> sent (note : we are the only sender, so the queue cannot get
> stopped while the tx lock was g
