On 20-08-2026 01:38, Stephen Hemminger wrote:
Summary of longish AI review..
Still open
Patch 15 — no response, and unchanged. getenv("DPAA_TX_TAILDROP_THRESHOLD") is
still the fallback, and the RST is still a bullet list. This is the one item that got no
reply at all, so it may just have been missed rather than rejected.
No plan to remove getenv for backward compatibility reasons.It is very
helpful in field debug without the need to change customers application
which generally embed DPDK devargs in the code. Documentation comment is
fixed.
Patch 19 — marked fixed, but only the commit message was. U48_BY_HI16_LO32() still shifts
hi by 32 with no cast, and BIT_SIZE/MAX_U48/HI16_OF_U48/LO32_OF_U48 are still unprefixed
in fsl_bman.h. The new message also says the macros were "dropped" when they
were moved into the installed header.
This is common firmware code. No plan to change every macro with
prefix. However, the U48_BY_HI16_LO32 issue is fixed.
Patch 22 — genuinely improved. MAX_NUM_PORTS/MAX_NUM_SUBNETS are prefixed (the
collision that actually mattered) and dpaa_ip4_addr_s → dpaa_ip_addr_s. Still
unprefixed in the installed header: struct ip_pair_s, struct lgw_subnet_s, and
the DPA_ISC_* macros. I'd narrow the remaining ask to just those.
ip_pair_s and lgw_subnet_s are prefixed. DPA_ISC is already a prefix;
no need to add more.
Patch 24 — unchanged in substance, and the contradiction is now sharper than in
v12: patch 13 deliberately made dpaa_mpool_finish() the only place
rte_dpaa_bpid_info is freed, so that function calls dpaax_enter_destructor()
and then rte_free() on EAL memory a few lines later. dpaa_finish() does the
same — latch, then dpaa_fm_term() and rte_dpaa_portal_fq_close().
Removing patch from the series
Patch 25 — new inconsistency introduced by the patch 14 fix: the release note still says
"Added NXP DPAA DMA scatter-gather support" and "Added scatter-gather (SG)
batching... enabled by default", which is exactly the claim patch 14's message was corrected
to drop.
fixed.
Patch 16 (ORP) — on "NXP customer applications use it":
qman_enqueue_multi_orp() is tagged __rte_internal, so it isn't reachable from an
application at all; internal symbols are restricted to DPDK's own libs and drivers. If
NXP customer code is calling it, either it's building in-tree (in which case that user
should come with the patch) or the tag is wrong. Worth putting back to them as a question
rather than a demand.
Removing the patch from the series
