• Marcin Wojtas's avatar
    net: mvneta: bm: add support for hardware buffer management · dc35a10f
    Marcin Wojtas authored
    Buffer manager (BM) is a dedicated hardware unit that can be used by all
    ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX
    path by sparing DRAM access on refilling buffer pool, hardware-based
    filling of descriptor ring data and better memory utilization due to HW
    arbitration for using 'short' pools for small packets.
    
    Tests performed with A388 SoC working as a network bridge between two
    packet generators 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 to 20% with BM.
    
    BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which
    are called external BP pools - BPPE. Allocating and releasing buffer
    pointers (BP) to/from BPPE is performed indirectly by write/read access
    to a dedicated internal SRAM, where internal BP pools (BPPI) are placed.
    BM hardware controls status of BPPE automatically, as well as assigning
    proper buffers to RX descriptors. For more details please refer to
    Functional Specification of Armada XP or 38x SoC.
    
    In order to enable support for a separate hardware block, common for all
    ports, a new driver has to be implemented ('mvneta_bm'). It provides
    initialization sequence of address space, clocks, registers, SRAM,
    empty pools' structures and also obtaining optional configuration
    from DT (please refer to device tree binding documentation). mvneta_bm
    exposes also a necessary API to mvneta driver, as well as a dedicated
    structure with BM information (bm_priv), whose presence is used as a
    flag notifying of BM usage by port. It has to be ensured that mvneta_bm
    probe is executed prior to the ones in ports' driver. In case BM is not
    used or its probe fails, mvneta falls back to use software buffer
    management.
    
    A sequence executed in mvneta_probe function is modified in order to have
    an access to needed resources before possible port's BM initialization is
    done. According to port-pools mapping provided by DT appropriate registers
    are configured and the buffer pools are filled. RX path is modified
    accordingly. Becaues the hardware allows a wide variety of configuration
    options, following assumptions are made:
    * using BM mechanisms can be selectively disabled/enabled basing
      on DT configuration among the ports
    * 'long' pool's single buffer size is tied to port's MTU
    * using 'long' pool by port is obligatory and it cannot be shared
    * using 'short' pool for smaller packets is optional
    * one 'short' pool can be shared among all ports
    
    This commit enables hardware buffer management operation cooperating with
    existing mvneta driver. New device tree binding documentation is added and
    the one of mvneta is updated accordingly.
    
    [gregory.clement@free-electrons.com: removed the suspend/resume part]
    Signed-off-by: default avatarMarcin Wojtas <mw@semihalf.com>
    Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    dc35a10f
Kconfig 4.97 KB