From: Jisheng Zhang <Jisheng.Zhang@synaptics.com> To: "Marek Behún" <marek.behun@nic.cz>, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>, "Andrew Lunn" <andrew@lunn.ch> Cc: linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, Gregory CLEMENT <gregory.clement@bootlin.com>, Tomas Hlavacek <tomas.hlavacek@nic.cz>, Russell King - ARM Linux <linux@armlinux.org.uk>, "David S. Miller" <davem@davemloft.net> Subject: Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720 Date: Thu, 9 Aug 2018 20:08:32 +0800 [thread overview] Message-ID: <20180809200832.7de1fa9e@xhacker.debian> (raw) In-Reply-To: <20180809192755.24e57782@xhacker.debian> On Thu, 9 Aug 2018 19:27:55 +0800 Jisheng Zhang wrote: > Hi, > > On Thu, 9 Aug 2018 12:40:41 +0800 Jisheng Zhang wrote: > > > + more people > > > > On Wed, 8 Aug 2018 17:27:05 +0200 Marek Behún wrote: > > > > > For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the > > > networking driver behaves weirdly when using napi_gro_receive. > > > > > > For example downloading a big file from a local network (low ping) is > > > fast, but when downloading from a remote server (higher ping), the > > > download speed is at first high but drops rapidly to almost nothing or > > > absolutely nothing. > > > > We also met this issue on some berlin platforms. I tried to fix the bug, > > but no clue so far. > > > > > > > > This is fixed when using netif_receive_skb instead of napi_gro_receive. > > > > This is a workaround. The good news is this workaround also fixes the issue > > we saw on berlin. > > > > > > > > Signed-off-by: Marek Behun <marek.behun@nic.cz> > > > Cc: Russell King - ARM Linux <linux@armlinux.org.uk> > > > Cc: netdev@vger.kernel.org > > > > > > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c > > > index 0ad2f3f7da85..27f3017d94c5 100644 > > > --- a/drivers/net/ethernet/marvell/mvneta.c > > > +++ b/drivers/net/ethernet/marvell/mvneta.c > > > @@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, > > > > > > skb->protocol = eth_type_trans(skb, dev); > > > mvneta_rx_csum(pp, rx_status, skb); > > > - napi_gro_receive(&port->napi, skb); > > > + if (pp->neta_armada3700) > > > + netif_receive_skb(skb); > > > + else > > > + napi_gro_receive(&port->napi, skb); > > I think I found the root cause, if neta_armada3700 is true, the port got from > this_cpu_ptr(pp->ports) is invalid, this is bug... I'll cook a patch for this correct it as: the port's(port is got from this_cpu_ptr(pp->ports) napi is invalid. Patch is sent out. Could you please try? Per my test, it solves the issue we saw on berlin. > > Thanks > > > > > > > rcvd_pkts++; > > > rcvd_bytes += rx_bytes; > > > @@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, > > > > > > mvneta_rx_csum(pp, rx_status, skb); > > > > > > - napi_gro_receive(&port->napi, skb); > > > + if (pp->neta_armada3700) > > > + netif_receive_skb(skb); > > > + else > > > + napi_gro_receive(&port->napi, skb); > > > } > > > > > > if (rcvd_pkts) { > > >
WARNING: multiple messages have this Message-ID (diff)
From: Jisheng.Zhang@synaptics.com (Jisheng Zhang) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720 Date: Thu, 9 Aug 2018 20:08:32 +0800 [thread overview] Message-ID: <20180809200832.7de1fa9e@xhacker.debian> (raw) In-Reply-To: <20180809192755.24e57782@xhacker.debian> On Thu, 9 Aug 2018 19:27:55 +0800 Jisheng Zhang wrote: > Hi, > > On Thu, 9 Aug 2018 12:40:41 +0800 Jisheng Zhang wrote: > > > + more people > > > > On Wed, 8 Aug 2018 17:27:05 +0200 Marek Beh?n wrote: > > > > > For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the > > > networking driver behaves weirdly when using napi_gro_receive. > > > > > > For example downloading a big file from a local network (low ping) is > > > fast, but when downloading from a remote server (higher ping), the > > > download speed is at first high but drops rapidly to almost nothing or > > > absolutely nothing. > > > > We also met this issue on some berlin platforms. I tried to fix the bug, > > but no clue so far. > > > > > > > > This is fixed when using netif_receive_skb instead of napi_gro_receive. > > > > This is a workaround. The good news is this workaround also fixes the issue > > we saw on berlin. > > > > > > > > Signed-off-by: Marek Behun <marek.behun@nic.cz> > > > Cc: Russell King - ARM Linux <linux@armlinux.org.uk> > > > Cc: netdev at vger.kernel.org > > > > > > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c > > > index 0ad2f3f7da85..27f3017d94c5 100644 > > > --- a/drivers/net/ethernet/marvell/mvneta.c > > > +++ b/drivers/net/ethernet/marvell/mvneta.c > > > @@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, > > > > > > skb->protocol = eth_type_trans(skb, dev); > > > mvneta_rx_csum(pp, rx_status, skb); > > > - napi_gro_receive(&port->napi, skb); > > > + if (pp->neta_armada3700) > > > + netif_receive_skb(skb); > > > + else > > > + napi_gro_receive(&port->napi, skb); > > I think I found the root cause, if neta_armada3700 is true, the port got from > this_cpu_ptr(pp->ports) is invalid, this is bug... I'll cook a patch for this correct it as: the port's(port is got from this_cpu_ptr(pp->ports) napi is invalid. Patch is sent out. Could you please try? Per my test, it solves the issue we saw on berlin. > > Thanks > > > > > > > rcvd_pkts++; > > > rcvd_bytes += rx_bytes; > > > @@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, > > > > > > mvneta_rx_csum(pp, rx_status, skb); > > > > > > - napi_gro_receive(&port->napi, skb); > > > + if (pp->neta_armada3700) > > > + netif_receive_skb(skb); > > > + else > > > + napi_gro_receive(&port->napi, skb); > > > } > > > > > > if (rcvd_pkts) { > > >
next prev parent reply other threads:[~2018-08-09 14:36 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-08 15:26 [PATCH v1 0/7] Add support for the Turris Mox router Marek Behún 2018-08-08 15:27 ` [PATCH v1 1/7] From: Ken Ma <make@marvell.com> Marek Behún 2018-08-08 16:49 ` Andrew Lunn 2018-08-08 15:27 ` [PATCH v1 2/7] drivers: mfd: Add support for Moxtet bus Marek Behún 2018-08-08 15:32 ` Marek Behún 2018-08-08 15:27 ` [PATCH v1 3/7] drivers: gpio: Add support for Turris Mox SFP GPIOs Marek Behún 2018-08-08 16:55 ` Andrew Lunn 2018-08-08 20:40 ` Marek Behun 2018-08-08 15:27 ` [PATCH v1 4/7] watchdog: Add support for Armada 37xx CPU watchdog Marek Behún 2018-08-08 15:27 ` [PATCH v1 5/7] arm64: dts: marvell: armada-37xx: add nodes to support watchdog Marek Behún 2018-08-08 15:27 ` [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720 Marek Behún 2018-08-08 15:27 ` Marek Behún 2018-08-08 16:58 ` Andrew Lunn 2018-08-08 16:58 ` Andrew Lunn 2018-08-08 17:57 ` Dave Taht 2018-08-08 17:57 ` Dave Taht 2018-08-09 4:40 ` Jisheng Zhang 2018-08-09 4:40 ` Jisheng Zhang 2018-08-09 11:27 ` Jisheng Zhang 2018-08-09 11:27 ` Jisheng Zhang 2018-08-09 12:08 ` Jisheng Zhang [this message] 2018-08-09 12:08 ` Jisheng Zhang 2018-08-21 10:07 ` Marek Behún 2018-08-21 10:07 ` Marek Behún 2018-08-08 15:27 ` [PATCH v1 7/7] ARM64: dts: marvell: Add DTS files for Turris Mox Marek Behún
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180809200832.7de1fa9e@xhacker.debian \ --to=jisheng.zhang@synaptics.com \ --cc=andrew@lunn.ch \ --cc=davem@davemloft.net \ --cc=gregory.clement@bootlin.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@armlinux.org.uk \ --cc=marek.behun@nic.cz \ --cc=netdev@vger.kernel.org \ --cc=thomas.petazzoni@bootlin.com \ --cc=tomas.hlavacek@nic.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.