On Thu, Nov 03, 2016 at 12:48:08PM +0200, Felipe Balbi wrote:
>
> 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?
> >>
> >
> > 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.
During this test, the data at rx is much more than tx, but throttling
interrupt we are discussing is at tx.
[ 1.314390] fec 21b4000.ethernet (unnamed net_device) (uninitialized): Invalid MAC addresspacket_write_wait: Connection to 192.168.1.1: Broken pipe
root@imx6qdlsolo:~# ifconfig usb0
usb0 Link encap:Ethernet HWaddr d6:c9:9a:18:4b:b1
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::d4c9:9aff:fe18:4bb1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5011 errors:0 dropped:0 overruns:0 frame:0
TX packets:677 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3015832 (2.8 MiB) TX bytes:94532 (92.3 KiB)
--
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
