On Wed, 7 Oct 2026 12:54:12 +0530
Hemant Agrawal <[email protected]> wrote:
> This series collects a set of fixes and enhancements for the NXP DPAA
> bus, mempool, dma, crypto and net drivers targeting 26.11.
>
> It includes memory-leak and resource-cleanup fixes on the device
> remove/close paths, more robust frame queue and congestion-group
> shutdown, secondary-process safety guards, BPID and cgrid lifecycle
> handling, and several new features: offline (O/H) port device support,
> enhanced virtual storage profile (VSP) port support, fmcless Rx queue
> configuration via devargs, Rx/Tx taildrop threshold devargs, non
> fmX-macY shared Ethernet naming, and DMA scatter-gather and
> errata-workaround devargs. Documentation and release notes are updated
> accordingly.
Really close the AI review is only complaining about stuff in the commit
messages.
Applies cleanly to main (1bad527). HEAD and each of the 27 commits
build with -Dwerror=true (gcc 13.3, x86) for the DPAA drivers. Not
built for arm64.
v22 addresses the v21 items. 25/27 and 26/27 now release an FQID
only after its queue shut down, 11/27 documents the probe behaviour
change, and 27/27 covers the new FMCLESS default. Ignore the 17/27
item from the v21 review: RTE_FINI_PRIO() token-pastes the priority
onto RTE_PRIORITY_, so the local define is needed.
What remains is commit message text in 01 and 11, plus minor items.
Warning
-------
Patch 01/27: The rewritten message names the wrong trigger for the
NULL dereference. dpaa_bus_cleanup() calls remove only for probed
devices (rte_dev_is_probed()), so a device that was never probed
does not get here. The real case is normal shutdown:
rte_eth_dev_close() releases the port, so at rte_eal_cleanup()
rte_eth_dev_allocated() returns NULL. Suggest:
The unconditional call also dereferenced eth_dev without checking
that rte_eth_dev_allocated() found anything. rte_eth_dev_close()
releases the port, so an application that closed its ports before
rte_eal_cleanup() crashed in remove.
Patch 11/27: The new paragraph gives the wrong reason for failing
the probe. qman_create_cgr() returns an error only before
list_add(), so a CGR whose creation failed is never linked. The
hazard is the error path this patch adds, which deletes one CGR per
initialised queue; the in-code comment already says so. Suggest:
This also changes probe behaviour: a qman_create_cgr() failure in
dpaa_rx_queue_init() or dpaa_tx_queue_init() now fails the probe
instead of continuing without tail drop on that queue. The probe
error path deletes one CGR per initialised queue, and a CGR whose
creation failed was never linked into the portal list.
Info
----
Patch 26/27: The commit message says range allocation reduces boot
and quit time, but dpaa_sec_uninit() now releases each FQID with
its own ioctl, 4096 of them for inq[]. Releasing contiguous runs
keeps the per-queue check:
uint32_t base = 0, run = 0;
for (i = 0; i < RTE_DPAA_MAX_RX_QUEUE; i++) {
fqid = internals->inq[i].fqid;
if (run && fqid != base + run) {
qman_release_fqid_range(base, run);
run = 0;
}
if (!fqid || qman_shutdown_fq(&internals->inq[i]))
continue; /* log as now */
if (run++ == 0)
base = fqid;
}
if (run)
qman_release_fqid_range(base, run);
Or drop "quit" from the commit message.
Patch 25/27: qman_create_fq() also takes an FQ lookup table entry on
64-bit builds, and only qman_destroy_fq() clears it. No DPAA
driver calls that, because qman_shutdown_fq() leaves fq->state
untouched and qman_destroy_fq() then does nothing. Each oldev
probe/close cycle leaks two of the 32K entries; dpaa_sec leaks
4098 per cycle (pre-existing). If qman_shutdown_fq() set
fq->state = qman_fq_state_oos on success, drivers could call
qman_destroy_fq(), which already releases a dynamic FQID and the
lookup entry.
Pre-existing, not introduced here: in FMCLESS mode net/dpaa never
releases the Rx FQIDs it gets from qman_alloc_fqid_range(), on close
or on probe failure.
