[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1710c5d8f447be2cf38c5c5e468186357b1388f2.camel@baylibre.com>
Date: Mon, 03 Sep 2018 10:56:47 +0200
From: Jerome Brunet <jbrunet@...libre.com>
To: Jose Abreu <Jose.Abreu@...opsys.com>, netdev@...r.kernel.org
Cc: Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
"David S. Miller" <davem@...emloft.net>,
Joao Pinto <Joao.Pinto@...opsys.com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>
Subject: Re: [RFT net-next] net: stmmac: Rework coalesce timer and fix
multi-queue races
On Thu, 2018-08-30 at 11:37 +0100, Jose Abreu wrote:
> [ As for now this is only for testing! ]
>
> This follows David Miller advice and tries to fix coalesce timer in
> multi-queue scenarios.
>
> We are now using per-queue coalesce values and per-queue TX timer. This
> assumes that tx_queues == rx_queues, which can not be necessarly true.
> Official patch will need to have this fixed.
>
> Coalesce timer default values was changed to 1ms and the coalesce frames
> to 25.
>
> Tested in B2B setup between XGMAC2 and GMAC5.
Tested on Amlogic meson-axg-s400. No regression seen so far.
(arch/arm64/boot/dts/amlogic/meson-axg-s400.dts)
As far as I understand from the device tree parsing, this platform (and all
other amlogic platforms) use single queue.
---
Jose,
On another topic doing iperf3 test on amlogic's devices we seen a strange
behavior.
Doing Tx or Rx test usually works fine (700MBps to 900MBps depending on the
platform). However, when doing both Rx and Tx at the same time, We see the Tx
throughput dropping significantly (~30MBps) and lot of TCP retries.
Would you any idea what might be our problem ? or how to start investigating
this ?
Powered by blists - more mailing lists