netdev - RE: high latency with imx8mm compared to imx6q

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DB9PR04MB8106FE7B686569FB15C3281388A69@DB9PR04MB8106.eurprd04.prod.outlook.com>
Date:   Sat, 18 Feb 2023 11:52:03 +0000
From:   Wei Fang <wei.fang@....com>
To:     Richard Weinberger <richard@....at>
CC:     Andrew Lunn <andrew@...n.ch>,
        David Laight <David.Laight@...lab.com>,
        netdev <netdev@...r.kernel.org>,
        Shenwei Wang <shenwei.wang@....com>,
        Clark Wang <xiaoning.wang@....com>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: high latency with imx8mm compared to imx6q


> -----Original Message-----
> From: Richard Weinberger <richard@....at>
> Sent: 2023年2月18日 17:43
> To: Wei Fang <wei.fang@....com>
> Cc: Andrew Lunn <andrew@...n.ch>; David Laight
> <David.Laight@...lab.com>; netdev <netdev@...r.kernel.org>; Shenwei
> Wang <shenwei.wang@....com>; Clark Wang <xiaoning.wang@....com>;
> dl-linux-imx <linux-imx@....com>
> Subject: Re: high latency with imx8mm compared to imx6q
> 
> ----- Ursprüngliche Mail -----
> > Von: "wei fang" <wei.fang@....com>
> >> > Is it just interrupt latency caused by interrupt coalescing to
> >> > avoid excessive interrupts?
> >>
> >> Just adding to this, it appears imx6q does not have support for
> >> changing the interrupt coalescing. imx8m does appear to support it.
> >> So try playing with ethtool -c/-C.
> >>
> > Yes, I agree with Andrew, the interrupt coalescence feature default to
> > be enabled on i.MX8MM platforms. The purpose of the interrupt
> > coalescing is to reduce the number of interrupts generated by the MAC
> > so as to reduce the CPU loading.
> > As Andrew said, you can turn down rx-usecs and tx-usecs, and then try again.
> 
> Hm, I thought my settings are fine (IOW no coalescing at all).
> Coalesce parameters for eth0:
> Adaptive RX: n/a  TX: n/a
> rx-usecs: 0
> rx-frames: 0
> tx-usecs: 0
> tx-frames: 0
> 
Unfortunately, the fec driver does not support to set rx-usecs/rx-frames/tx-usecs/tx-frames
to 0 to disable interrupt coalescing. 0 is an invalid parameters. :(

> 
> But I noticed something interesting this morning. When I set rx-usecs, tx-usecs,
> rx-frames and tx-frames to 1, *sometimes* the RTT is good.
> 
> PING 192.168.0.52 (192.168.0.52) 56(84) bytes of data.
> 64 bytes from 192.168.0.52: icmp_seq=1 ttl=64 time=0.730 ms
> 64 bytes from 192.168.0.52: icmp_seq=2 ttl=64 time=0.356 ms
> 64 bytes from 192.168.0.52: icmp_seq=3 ttl=64 time=0.303 ms
> 64 bytes from 192.168.0.52: icmp_seq=4 ttl=64 time=2.22 ms
> 64 bytes from 192.168.0.52: icmp_seq=5 ttl=64 time=2.54 ms
> 64 bytes from 192.168.0.52: icmp_seq=6 ttl=64 time=0.354 ms
> 64 bytes from 192.168.0.52: icmp_seq=7 ttl=64 time=2.22 ms
> 64 bytes from 192.168.0.52: icmp_seq=8 ttl=64 time=2.54 ms
> 64 bytes from 192.168.0.52: icmp_seq=9 ttl=64 time=2.53 ms
> 
> So coalescing plays a role but it looks like the ethernet controller does not
> always obey my settings.
> I didn't look into the configured registers so far, maybe ethtool does not set
> them correctly.
> 
It look a bit weird. I did the same setting with my i.MX8ULP and didn't have this
issue. I'm not sure whether you network is stable or network node devices also
enable interrupt coalescing and the relevant parameters are set to a bit high.