<div dir="ltr"><div dir="ltr">That makes sense. I guess missing TX completion could be potential suspect and I'll check on that. <div><br></div><div>On the other hand, why I ask about back-pressure is because when the problem happens the UDP TX socket shows as stuck and doesn't take any new packets. </div><div>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">~# netstat -tulnp</span></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">Active Internet connections (only servers)</span></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">Proto Recv-Q Send-Q Local Address <span class="gmail-Apple-converted-space"> </span>Foreign Address <span class="gmail-Apple-converted-space"> </span>State <span class="gmail-Apple-converted-space"> </span>PID/Program name <span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">udp</span><span class="gmail-Apple-converted-space" style="font-variant-ligatures:no-common-ligatures"> </span><span style="font-variant-ligatures:no-common-ligatures">0 </span><span class="gmail-Apple-converted-space" style="font-variant-ligatures:no-common-ligatures"> </span><span style="font-variant-ligatures:no-common-ligatures">22400 <a href="http://0.0.0.0:48439">0.0.0.0:48439</a> </span><span class="gmail-Apple-converted-space" style="font-variant-ligatures:no-common-ligatures"> </span><span style="font-variant-ligatures:no-common-ligatures">0.0.0.0:* </span><span class="gmail-Apple-converted-space" style="font-variant-ligatures:no-common-ligatures"> </span><span style="font-variant-ligatures:no-common-ligatures">2407/audiod-xxxxx</span><br></p></div></div><div><br></div><div>Basically the "Send-Q" number stays as a very high number for long time (I didn't save what the exact number is when the problem happens) in the above example, so that the sendto() function simply fails.</div><div>This is why I wondered about back-pressure being applied. Otherwise shouldn't UDP socket keeps sending and packets would be dropped by the queue scheduler?</div><div><br></div><div>Thanks,</div><div>Joshua</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 12, 2019 at 12:57 PM Toke Høiland-Jørgensen <<a href="mailto:toke@redhat.com">toke@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Joshua Zhao <<a href="mailto:swzhao@gmail.com" target="_blank">swzhao@gmail.com</a>> writes:<br>
<br>
> Hi,<br>
> Thanks for the reply! I've also emailed the ath10k and linux-wireless list<br>
> and waiting to hear back suggestions.<br>
> In the meantime can you educate me how the aqm queue interacts with wifi<br>
> driver? Is that the driver pulls from the queue from time to time, instead<br>
> of aqm pushes to the network interface? How often or what triggers the<br>
> driver to pull?<br>
<br>
Generally two paths:<br>
<br>
1. Packet comes in from upper netdev -> mac80211 queues the packet to tx -><br>
driver is notified through wake_tx_queue() op, driver initiates<br>
transmission scheduling and pulls from TXQ<br>
<br>
and<br>
<br>
2. Driver gets notification from hardware (mostly TX completion) -><br>
driver initiates TX scheduling and pulls from TXQ<br>
<br>
There are some more cases that are variants of the above (e.g., wakeup<br>
from powersave etc). My guess is that in your case it is one of the<br>
cases in the second category that goes wrong...<br>
<br>
> I hope I can verify that if you can point me to the code to check that<br>
> :) And, for the queue itself, how long it's supposed to drop packets<br>
> and clean up?<br>
<br>
Well, when the hardware is reset, or the station is disassociated, the<br>
queue will be flushed. Other than that, there's no separate "cleanup"<br>
per se; rather, the two mechanisms outlined above should ensure that<br>
packets keep flowing towards the station at the other end.<br>
<br>
> It seems that when it's full, it notifies back-pressure to the socket<br>
> instead of simply dropping the packets from the head or the tail of<br>
> the queue?<br>
<br>
No, it doesn't generally do much back-pressure. Rather, when it fills<br>
up, it will drop packets from the head of the longest flow to clear<br>
space (see fq_tin_enqueue()). The limit is pretty high, though - 8192<br>
packets or 16 Mbytes of memory...<br>
<br>
-Toke<br>
</blockquote></div></div>