From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC Date: Sun, 16 Dec 2018 16:00:28 -0800 Message-ID: References: <87r2f2pxpa.fsf@miraculix.mork.no> <87pnu8vepj.fsf@notabene.neil.brown.name> <87a7l5azux.fsf@notabene.neil.brown.name> <20181216.141458.260639209068679776.davem@davemloft.net> <875zvtawlh.fsf@notabene.neil.brown.name> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: bjorn@mork.no, gerg@kernel.org, sean.wang@mediatek.com, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com, netdev@vger.kernel.org, blogic@openwrt.org, opensource@vdorst.com To: NeilBrown , David Miller Return-path: Received: from mail-ot1-f67.google.com ([209.85.210.67]:41322 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730719AbeLQAAf (ORCPT ); Sun, 16 Dec 2018 19:00:35 -0500 Received: by mail-ot1-f67.google.com with SMTP id u16so10562669otk.8 for ; Sun, 16 Dec 2018 16:00:35 -0800 (PST) In-Reply-To: <875zvtawlh.fsf@notabene.neil.brown.name> Sender: netdev-owner@vger.kernel.org List-ID: On December 16, 2018 3:19:22 PM PST, NeilBrown wrote: >On Sun, Dec 16 2018, David Miller wrote: > >> From: NeilBrown >> Date: Mon, 17 Dec 2018 09:08:54 +1100 >> >>> In my 4=2E4 kernel, the build_skb() call in (the equivalent of) >>> mtk_poll_rx() takes about 1=2E2usec and the call to napi_gro_receive() >>> takes about 3usec=2E >>>=20 >>> In my 4=2E20 kernel, these calls take about 30 and 24 usec >respectively=2E >>> This easily explains the slowdown=2E >> >> That's a huge difference=2E >> >> Nothing jumps out as a possible cause except perhaps retpoline or >> something like that=2E > >I'll keep that in mind - thanks=2E > >My guess was CPU-cache invalidation=2E >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=2E >About 17KB transferred per IPI=2E >I cannot see where build_skb() would do cache invalidation though=2E It doesn't the driver is responsible for that=2E How is coherency maintain= ed between cores? The IPI could be due to receive packet steering, is the MAC multi queue aw= are on the RX path? --=20 Florian