Re: [PATCH] usb: gadget: u_ether: remove interrupt throttling

[Felipe Balbi <felipe.balbi@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2808 bytes --]


Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
>> Peter Chen <hzpeterchen@gmail.com> writes:
>> >> > Peter Chen <hzpeterchen@gmail.com> writes:
>> >> > > On Wed, Nov 02, 2016 at 11:22:54AM -0400, David Miller wrote:
>> >> > >> From: Peter Chen <hzpeterchen@gmail.com>
>> >> > >> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]