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: <130183416.146934.1676713353800.JavaMail.zimbra@nod.at>
Date:   Sat, 18 Feb 2023 10:42:33 +0100 (CET)
From:   Richard Weinberger <richard@....at>
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>,
        xiaoning wang <xiaoning.wang@....com>,
        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
stats-block-usecs: n/a
sample-interval: n/a
pkt-rate-low: n/a
pkt-rate-high: n/a

rx-usecs: 0
rx-frames: 0
rx-usecs-irq: n/a
rx-frames-irq: n/a

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: n/a
tx-frames-irq: n/a

rx-usecs-low: n/a
rx-frame-low: n/a
tx-usecs-low: n/a
tx-frame-low: n/a

rx-usecs-high: n/a
rx-frame-high: n/a
tx-usecs-high: n/a


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.

Thanks,
//richard