AR6000 netif_queue_stop non stop, Bug?

[Werner Almesberger]

Ivan Petrov wrote:
> Changes: Data queue in driver reducted to one packet, for use kernel packet management engine.
> Changes: Queue WMI_CONTROL_PRI full/available control fully moved to ar6000_tx_queue_full/ar6000_tx_queue_available.
> Changes: Small cleanup.

Looks great ! Now, let's fix the description and then I can apply it.

> Comment:
> Additional advantages at reducted data queue.
> At this moment driver work in pseudo asynchronous mode, it mean, what 
> transfer start only after 'io' thread take control, before it moment all 
> packets will collected in hif2 layer queue.

Does this sound correct ?

"At this moment the driver works in a pseudo-asynchronous mode. This
 means, that a transfer starts only after the 'io' thread takes control.
 Before this moment, all packets will be collected in the hif2 layer
 queue."

> Critical packet - packet with 
> frlag on request additional credits.

I didn't understand this. What's "frlag" ? "flag" ? What flag would
that be ?

> If we have prancing (saltatory)

"bursty" ?

> trafic from kernel side, this packet will send only after driver queue 
> will fully filled or kernel queue will empty.

Hmm, I don't understand this one. But perhaps it will become clear
when you've explained the part above.

> In this case we get conveyor fail,

Did you mean "queue overflow" ?

> and lost of time (about ms).

Do you mean a retransmission because the packet was lost ?

> Reducting queue length allow 
> to fast send the critical packcket and receive back new credits.

Yup :)

> For werner, sorry today not read Documents\..., if not fully cleanup,
> please write, I will correct it.

We're getting there :-) The path names were already good. 

Thanks,
- Werner