brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

[Jérôme Carretero]

Hi,


I've crippled a Raspberry Pi 3 (1 core, 200 MHz) and observed that the
glomming feature has a definite impact on TX performance, but it looks
like at this CPU frequency, the work queue is solicited "too often"
by brcmf_sdio_trigger_dpc() and glomming is only doing 4 packets at
once, resulting in maybe a sub-optimal throughput.


I have a vague idea that deliberately delaying the transmissions so as
to wait for either a small timeout, or the glomming level has been
reached, would be something worth exploring.
But I haven't spent a long time looking at the driver.


I'm just soliciting your advice at this point, I'll do some experiments
also.


Best regards,

--=20
J=C3=A9r=C3=B4me

Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

[Jörg Krause]

Hi Jérôme,

On Wed, 2017-05-24 at 07:33 -0400, Jérôme Carretero wrote:
> Hi,
> 
> 
> I've crippled a Raspberry Pi 3 (1 core, 200 MHz) and observed that the
> glomming feature has a definite impact on TX performance, but it looks
> like at this CPU frequency, the work queue is solicited "too often"
> by brcmf_sdio_trigger_dpc() and glomming is only doing 4 packets at
> once, resulting in maybe a sub-optimal throughput.

I'm experiencing low throughput with a BCM43362 wifi chip attached via
SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm
getting now a TCP throughput of 12.5 Mbps for the wifi interface, which
is still below the throughput I get for the Cubietruck.

> 
> I have a vague idea that deliberately delaying the transmissions so as
> to wait for either a small timeout, or the glomming level has been
> reached, would be something worth exploring.
> But I haven't spent a long time looking at the driver.

If you are in need for any testing I'm willing to help!

[1] https://www.spinics.net/lists/linux-wireless/msg153257.html	
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/
461137.html

Jörg

Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

[Fabio Estevam]

Hi J=C3=B6rg,

On Thu, Jun 1, 2017 at 3:37 AM, J=C3=B6rg Krause <joerg.krause@embedded.roc=
ks> wrote:

> I'm experiencing low throughput with a BCM43362 wifi chip attached via
> SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm
> getting now a TCP throughput of 12.5 Mbps for the wifi interface, which
> is still below the throughput I get for the Cubietruck.

Does it help if you disable CONFIG_PROVE_LOCKING?

--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -175,7 +175,6 @@ CONFIG_MAGIC_SYSRQ=3Dy
 CONFIG_DEBUG_KERNEL=3Dy
 CONFIG_LOCKUP_DETECTOR=3Dy
 CONFIG_TIMER_STATS=3Dy
-CONFIG_PROVE_LOCKING=3Dy
 CONFIG_BLK_DEV_IO_TRACE=3Dy
 CONFIG_STRICT_DEVMEM=3Dy
 CONFIG_DEBUG_USER=3Dy

Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

[Jörg Krause]

Hi Fabio,

On Fri, 2017-08-18 at 08:50 -0300, Fabio Estevam wrote:
> Hi Jörg,
> 
> On Thu, Jun 1, 2017 at 3:37 AM, Jörg Krause <joerg.krause@embedded.rocks> wrote:
> 
> > I'm experiencing low throughput with a BCM43362 wifi chip attached via
> > SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm
> > getting now a TCP throughput of 12.5 Mbps for the wifi interface, which
> > is still below the throughput I get for the Cubietruck.
> 
> Does it help if you disable CONFIG_PROVE_LOCKING?

No, it does not. I've disabled all settings in "Lock Debugging", but
the TCP throughput is still at ~12.5 Mpbs.

> --- a/arch/arm/configs/mxs_defconfig
> +++ b/arch/arm/configs/mxs_defconfig
> @@ -175,7 +175,6 @@ CONFIG_MAGIC_SYSRQ=y
>  CONFIG_DEBUG_KERNEL=y
>  CONFIG_LOCKUP_DETECTOR=y
>  CONFIG_TIMER_STATS=y
> -CONFIG_PROVE_LOCKING=y
>  CONFIG_BLK_DEV_IO_TRACE=y
>  CONFIG_STRICT_DEVMEM=y
>  CONFIG_DEBUG_USER=y