Hi, Peter Chen <hzpeterchen@xxxxxxxxx> writes: >> Peter Chen <hzpeterchen@xxxxxxxxx> writes: >> >> > Peter Chen <hzpeterchen@xxxxxxxxx> writes: >> >> > > On Wed, Nov 02, 2016 at 11:22:54AM -0400, David Miller wrote: >> >> > >> From: Peter Chen <hzpeterchen@xxxxxxxxx> >> >> > >> Date: Wed, 2 Nov 2016 14:02:02 +0800 >> >> > >> >> >> > >> > Felipe, it may increase cpu utilization since more interrupts will be there, >> >> > >> > it may affect the SoC which has lower cpu frequency. This code existed >> >> > >> > many years, why this problem has only reported at dwc3 recently? >> >> > >> >> >> > >> It's a bug, and it's going to cause TCP sockets to potentially hang. >> >> > >> >> >> > > >> >> > > For some controllers, it is, so we need to add parameter for user >> >> > > to see if interrupt migration is supported or not. >> >> > >> >> > not for some controller, for ALL networking drivers. >> >> > >> >> > > But just like some ethernet controllers, some USB controllers support >> >> > > hardware timeout mechanism which interrupt will be triggered after >> >> > > some uFrame occurs if the transaction has completed but not required >> >> > > to interrupt, it is used to support interrupt migration like ethernet. >> >> > >> >> > you're missing the point. What Dave Miller is saying is that it's ALWAYS >> >> > a bug to delay completion of SKBs. The only thing you're doing with >> >> > chipidea is delaying interrupt by up to 125us; which is still a bug from >> >> > the point of view of the networking layer, but it's more difficult to >> >> > perceive any problems because of the short time where interrupt is >> >> > delayed. >> >> > >> >> >> >> If it is ALWAYS a bug to delay completion of SKBs, how the local >> >> ethernet driver designs interrupt migration? >> >> >> > >> > Just a quick test, I delete dev_kfree_skb_any at tx_complete, not find >> > any problems by using simple "ping test", just free memory is less and >> > less. David, do you really mean free tx skb buffer with limited time, >> > but not return NETDEV_TX_OK by ->ndo_start_xmit with limited time? >> >> ping *will* work just fine. One easy test to *see* the problem is to SSH >> to a machine using g_ether, then run: >> >> $ while true; do dmesg; done >> >> you will notice it is rather laggy. Now remove throttling and the lags >> are gone. >> > > I have ran the test using ncm, the qmult is 10, but not find the laggy > at the screen, just the pipe will be broken after several minutes. the reason you don't see it is because of your forced per-uFrame interrupt. If you remove that, then you're likely going to have issues. Also, the fact that we're running Super-speed while you're running High-speed can also change things. -- balbi
Attachment:
signature.asc
Description: PGP signature