Page MenuHomeFreeBSD

dpaa: Migrate from NCSW base to a home-grown driver
AbandonedPublic

Authored by jhibbits on Fri, Apr 24, 3:38 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, May 15, 9:14 PM
Unknown Object (File)
Thu, May 14, 4:33 AM
Unknown Object (File)
Thu, May 14, 2:48 AM
Unknown Object (File)
Mon, May 11, 9:13 AM
Unknown Object (File)
Sat, May 9, 7:51 AM
Unknown Object (File)
Thu, May 7, 6:29 AM
Unknown Object (File)
Wed, May 6, 11:22 PM
Unknown Object (File)
Wed, May 6, 4:50 PM

Details

Summary

The NCSW reference base requires tuning for each target, and currently
is configured for FMANv2. This doesn't readily work on FMANv3 devices,
such as the T-series powerpc, or the LS1043 ARM. Since Freescale/NXP
abandoned the NCSW driver a decade ago, it makes sense to abandon it
ourselves as well. This new driver uses a combination of the NCSW
driver and the Linux driver (BSD/GPL dual licensed) as a reference, but
contains no actual code from them.

The DPAA (Data Path Acceleration Architecture) subsystem consists of the
following components:

  • BMan -- Buffer Manager. Manages buffer pools of different sizes (one size per pool, up to 64 pools)
  • QMan -- Queue Manager. Manages the interfaces between DPAA-based components and the CPU(s).
  • FMan -- Frame Manager. Responsible for all ethernet-related processing. Consists itself of the following components:
    • Ports -- interfaces to the QMan. An ethernet interface consists of 2 ports. Ports use "Next-invoked action" (NIA) descriptors to form a pipeline for processing on receive and transmit.
    • Parser -- performs protocol header parsing and validation. Both hardware and software parsers are available.
    • KeyGen -- Key generator, used to start the classification process (for the Policer), generating FQIDs and other keys based on the frame input.
    • Policer -- performs traffic shaping and classification
  • MAC -- SoC specific ethernet MAC (dTSEC, TGEC, mEMAC). Currently supports dTSEC and mEMAC, along with their MDIO blocks.

Additional components not yet handled:
SEC -- Security engine (crypto)
RE -- RAID engine
RapidIO
DCE -- Decompression/Compression engine, supports ZLIB, DEFLATE, and
GZIP, as well as base64 encoding and decoding.

BMan and QMan are accessed via cache-coherent portals, using ring
buffers as I/O. The intent is for portals to be per-CPU (core/thread)
to reduce locking contention and improve performance. This driver pins
interrupt handlers to the CPU "owning" a given portal, and uses critical
sections to prevent switching while accessing the portal.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 72504
Build 69387: arc lint + arc unit

Event Timeline

I'm unsure whether style items are left for later, but since I'm aware of them. Hopefully D48449 gets in soon and fixes the issues I'm aware of which have been suppressing use of macros.

sys/dev/dpaa/bman_fdt.c
101–105

Clearly it was here before, but while here... <cough, cough>

sys/dev/dpaa/dpaa_eth.c
515

Bit of development cleanup?

sys/dev/dpaa/fman_fdt.c
53

Minor nit here.

sys/dev/dpaa/fman_xmdio.c
102

Style.

111–115

<cough, cough>

Most drivers the equivalent is immediately after the method list.

sys/dev/dpaa/if_dtsec.c
95

Planned for cleanup before bringing into FreeBSD?

214–219

Ideally removed before bringing into FreeBSD?

sys/dev/dpaa/if_dtsec_fdt.c
169

Nudge, nudge.

sys/dev/dpaa/if_memac.c
113

Possibly due to starting from non-blank file?

700–704

Hmm.

sys/dev/dpaa/if_memac_fdt.c
79

I'm sure we know about this.

82–86

<cough, cough>

sys/dev/dpaa/qman_fdt.c
105–109

<cough, cough>

If you need to modify the section cleanup would be good.

Using a designated initializer for qman_errors should be a significant win longer term. At this point I think I've fully figured out how the mess with the DEFINE_CLASS*() macros occurred so I'm going to bring those up all the time. Hopefully someone with better knowledge of the previous driver will provide better comments on the algorithms soon.

sys/dev/dpaa/bman.h
30–31

Usually the header in sys would be #included first. I could readily believe sys/vmem.h depends on machine/vmparam.h, but doesn't #include that.

sys/dev/dpaa/dpaa_common.c
6–7

Usually a blank line between these two.

sys/dev/dpaa/fman.h
30–31

Wrong order unless this is needed due to issues.

sys/dev/dpaa/fman_muram.c
29–33

Unusual header ordering here. I can readily believe these headers are an exception to the normal rules though.

sys/dev/dpaa/fman_port.c
28–33

Non-standard ordering here. Also need a blank line after the sys headers.

697–698

Due to the problem with the DEFINE_CLASS_#() macros fman_port_driver will be global. D48449 aims to fix that, but I'm unsure when/if that will get in. Usually there would also be a blank line between the two macros.

sys/dev/dpaa/fman_xmdio.c
27–32

Comment I've already mentioned. Yet again I can readily accept this being an exception to the standard sorting.

sys/dev/dpaa/if_memac.c
7–14

I can accept the first four being exceptions to the normal rules, but I thought the others had been checked and could be in alphabetical/ASCII ordering.

sys/dev/dpaa/if_memac_fdt.c
27–33

Comment I've already mentioned. Yet again I can readily accept this being an exception to the standard sorting.

sys/dev/dpaa/qman.c
167–199

Wouldn't this be better as a designated initializer? Current style allows using such and this is a good match here. Then have a _Static_assert() before use to ensure it is the correct size.

sys/dev/dpaa/qman.h
30–31

Ordering.