netdev - Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

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]

Date:   Sun, 16 Dec 2018 16:00:28 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     NeilBrown <neil@...wn.name>, David Miller <davem@...emloft.net>
CC:     bjorn@...k.no, gerg@...nel.org, sean.wang@...iatek.com,
        andrew@...n.ch, vivien.didelot@...oirfairelinux.com,
        netdev@...r.kernel.org, blogic@...nwrt.org, opensource@...rst.com
Subject: Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC



On December 16, 2018 3:19:22 PM PST, NeilBrown <neil@...wn.name> wrote:
>On Sun, Dec 16 2018, David Miller wrote:
>
>> From: NeilBrown <neil@...wn.name>
>> Date: Mon, 17 Dec 2018 09:08:54 +1100
>>
>>> In my 4.4 kernel, the build_skb() call in (the equivalent of)
>>> mtk_poll_rx() takes about 1.2usec and the call to napi_gro_receive()
>>> takes about 3usec.
>>> 
>>> In my 4.20 kernel, these calls take about 30 and 24 usec
>respectively.
>>> This easily explains the slowdown.
>>
>> That's a huge difference.
>>
>> Nothing jumps out as a possible cause except perhaps retpoline or
>> something like that.
>
>I'll keep that in mind - thanks.
>
>My guess was CPU-cache invalidation.
>I just checked and the other CPU core (there are two - each
>hyper-threaded - "other" meaning not the one that handles ethernet
>interrupts) gets several thousand "IPI resched" interrupts while
>running a 10 second (226MByte) iperf3 receive test.
>About 17KB transferred per IPI.
>I cannot see where build_skb() would do cache invalidation though.

It doesn't the driver is responsible for that. How is coherency maintained between cores?

The IPI could be due to receive packet steering, is the MAC multi queue aware on the RX path?
-- 
Florian