AR6000 netif_queue_stop non stop, Bug?

Dear Werner,
> 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 ?
Yes, 'flag'. Need will use speel check in future.
>> If we have prancing (saltatory)
>> "bursty" ?
Bursty - yes, I take not correct word from dictionary.
>> 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" ?
No, I mean just conveyor fail, becouse every section make own part of work, dependet at prvious section result, and in theory I see
on it as parallel process.
"queue overflow" - it sequel at conveyor fail.
>> and lost of time (about ms).
>> Do you mean a retransmission because the packet was lost ?
Again not. Queue have stoped while not retrived new 'credits'. New credits coming time depend at time, while we request it. i.e. we
can request it while not credits, or at moment when queue full, second action can be delayed. Sample at end of mail.
>> Reducting queue length allow
>> to fast send the critical packcket and receive back new credits.
>> Yup :)
>
Flag, Critical packet, etc... next code mark packet for request credits.
function HTCTrySend(...
+ /* check if we need credits */
+ if (pEndpoint->CreditDist.TxCredits < pEndpoint->CreditDist.TxCreditsPerMaxMsg) {
+ sendFlags |= HTC_FLAGS_NEED_CREDIT_UPDATE;
+ INC_HTC_EP_STAT(pEndpoint, TxCreditLowIndications, 1);
+ AR_DEBUG_PRINTF(ATH_DEBUG_SEND,(" Host Needs Credits \n"));
+ }
>> 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.
Sample task:
Algo:
1.1. Take packet from kernel queue, while queue not empty, and give it to driver.
1.2. If queue empty, or interface stopped goto 3.1
2.1. Driver conver it to device format.
2.2. If Driver credits available, send it to HIF queue
2.3 If it last credits, mark packet for requet additional credits
2.4 If no credits, store it to internal driver queue.
2.5 If queue full, stop Kernel queue.
2.6. goto #1.1
3.0. HIF layer take packets and send it to card
Lets, on kernel queue lay 32 packets, driver have 6 credits and internal queue depth 32 node, we start transfer.
Algo fail - #2.4, 2.5 not allow request additional credits, for take it back as fast as posible. Request will send only after all 32
packet will pushed to driver queue.