Re: [PATCH 00/13] mvneta Buffer Management and enhancements

[Gregory CLEMENT]

Hi Marcin,
 
 On dim., nov. 22 2015, Marcin Wojtas <mw@xxxxxxxxxxxx> wrote:

> Hi,
>
> Hereby I submit a patchset that introduces various fixes and support
> for new features and enhancements to the mvneta driver:
>
> 1. First three patches are minimal fixes, stable-CC'ed.
>
> 2. Suspend to ram ('s2ram') support. Due to some stability problems
> Thomas Petazzoni's patches did not get merged yet, but I used them for
> verification. Contrary to wfi mode ('standby' - linux does not
> differentiate between them, so same routines are used) all registers'
> contents are lost due to power down, so the configuration has to be
> fully reconstructed during resume.
>
> 3. Optimisations - concatenating TX descriptors' flush, basing on
> xmit_more support and combined approach for finalizing egress processing.
> Thanks to HR timer buffers can be released with small latency, which is
> good for low transfer and small queues. Along with the timer, coalescing
> irqs are used, whose threshold could be increased back to 15.
>
> 4. Buffer manager (BM) support with two preparatory commits. As it is a
> separate block, common for all network ports, a new driver is introduced,
> which configures it and exposes API to the main network driver. It is
> throughly described in binding documentation and commit log. Please note,
> that enabling per-port BM usage is done using phandle and the data passed
> in mvneta_bm_probe. It is designed for usage of on-demand device probe
> and dev_set/get_drvdata, however it's awaiting merge to linux-next.
> Therefore, deferring probe is not used - if something goes wrong (same
> in case of errors during changing MTU or suspend/resume cycle) mvneta
> driver falls back to software buffer management and works in a regular way.
>
> Known issues:
> - problems with obtaining all mapped buffers from internal SRAM, when
> destroying the buffer pointer pool
> - problems with unmapping chunk of SRAM during driver removal
> Above do not have an impact on the operation, as they are called during
> driver removal or in error path.
>
> 5. Enable BM on Armada XP and 38X development boards - those ones and
> A370 I could check on my own. In all cases they survived night-long
> linerate iperf. Also tests were performed with A388 SoC working as a
> network bridge between two packet generators. They showed increase of
> maximum processed 64B packets by ~20k (~555k packets with BM enabled
> vs ~535 packets without BM). Also when pushing 1500B-packets with a
> line rate achieved, CPU load decreased from around 25% without BM vs
> 18-20% with BM.

I was trying to test the BM part of tour series on the Armada XP GP
board. However it failed very quickly during the pool allocation. After
a first debug I found that the size of the cs used in the
mvebu_mbus_dram_info struct was 0. I have applied your series on a
v4.4-rc1 kernel. At this stage I don't know if it is a regression in the
mbus driver, a misconfiguration on my side or something else.

Does it ring a bell for you?

How do you test test it exactly?
Especially on which kernel and with which U-Boot?

Thanks,

Gregory


>
> I'm looking forward to any remarks and comments.
>
> Best regards,
> Marcin Wojtas
>
> Marcin Wojtas (12):
>   net: mvneta: add configuration for MBUS windows access protection
>   net: mvneta: enable IP checksum with jumbo frames for Armada 38x on
>     Port0
>   net: mvneta: fix bit assignment in MVNETA_RXQ_CONFIG_REG
>   net: mvneta: enable suspend/resume support
>   net: mvneta: enable mixed egress processing using HR timer
>   bus: mvebu-mbus: provide api for obtaining IO and DRAM window
>     information
>   ARM: mvebu: enable SRAM support in mvebu_v7_defconfig
>   net: mvneta: bm: add support for hardware buffer management
>   ARM: mvebu: add buffer manager nodes to armada-38x.dtsi
>   ARM: mvebu: enable buffer manager support on Armada 38x boards
>   ARM: mvebu: add buffer manager nodes to armada-xp.dtsi
>   ARM: mvebu: enable buffer manager support on Armada XP boards
>
> Simon Guinot (1):
>   net: mvneta: add xmit_more support
>
>  .../bindings/net/marvell-armada-370-neta.txt       |  19 +-
>  .../devicetree/bindings/net/marvell-neta-bm.txt    |  49 ++
>  arch/arm/boot/dts/armada-385-db-ap.dts             |  20 +-
>  arch/arm/boot/dts/armada-388-db.dts                |  17 +-
>  arch/arm/boot/dts/armada-388-gp.dts                |  17 +-
>  arch/arm/boot/dts/armada-38x.dtsi                  |  20 +-
>  arch/arm/boot/dts/armada-xp-db.dts                 |  19 +-
>  arch/arm/boot/dts/armada-xp-gp.dts                 |  19 +-
>  arch/arm/boot/dts/armada-xp.dtsi                   |  18 +
>  arch/arm/configs/mvebu_v7_defconfig                |   1 +
>  drivers/bus/mvebu-mbus.c                           |  51 ++
>  drivers/net/ethernet/marvell/Kconfig               |  14 +
>  drivers/net/ethernet/marvell/Makefile              |   1 +
>  drivers/net/ethernet/marvell/mvneta.c              | 660 +++++++++++++++++++--
>  drivers/net/ethernet/marvell/mvneta_bm.c           | 642 ++++++++++++++++++++
>  drivers/net/ethernet/marvell/mvneta_bm.h           | 171 ++++++
>  include/linux/mbus.h                               |   3 +
>  17 files changed, 1677 insertions(+), 64 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/marvell-neta-bm.txt
>  create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.c
>  create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.h
>
> -- 
> 1.8.3.1
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/