On Thu, Nov 03, 2016 at 09:04:54AM +0200, Felipe Balbi wrote: > > Hi, > > 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? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
