On Mon, Nov 07, 2016 at 02:36:51PM +0200, Felipe Balbi wrote: > > 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. > I admit you are right, but if we can force complete interrupt occur within limited time, it should be OK. For chipidea, there are no option to disable forcing interrupt, you can only tune the threshold for forcing interrupt, the maximum is 8ms. > Also, the fact that we're running Super-speed while you're running > High-speed can also change things. > I don't think it is the reason, you can downgrade your speed and try again, I think you still will meet issue. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html