Hi, 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? what driver are you talking about? Which "local" ethernet driver? Also, do you mean 'moderation' instead of 'migration? -- balbi
Attachment:
signature.asc
Description: PGP signature