On Wed, 10 Jun 2026 09:39:35 +0800 [email protected] wrote: > From: Jie Liu <[email protected]> > > Introduce private testpmd commands and implementation files to enable > debugging and testing of sxe2-specific hardware features (such as > packet scheduling reset, UDP tunnel configuration, and IPsec ingress/ > egress offloads) directly within the testpmd application. > > The parameters are parsed using the standard 'rte_kvargs' library during > the PCI/vdev probing phase. Documentation for these parameters is also > updated. > > During memory hotplug events, the SXE2 driver needs to track memory > segment layout changes to maintain internal DMA mappings. However, > existing memseg walk functions (rte_memseg_walk) acquire memory locks > and cannot be called from within memory event callbacks, leading to > potential deadlocks. > > This commit introduces sxe2_memseg_walk_cb() as a helper that walks > memory segments using the thread-unsafe variant > rte_memseg_walk_thread_unsafe(), which is safe to call from > memory-related callbacks [citation:1][citation:3][citation:5]. > > The implementation follows the standard rte_memseg_walk_t prototype, > processing each memseg to update driver-specific data structures. > > Signed-off-by: Jie Liu <[email protected]> > ---
This memory stuff looks problematic and needs more review. At a minimum I see a pattern of not handling values from strtoul() that are out of range. I asked AI for a more detailed review and it saw. [PATCH 19/20] drivers: add testpmd commands for private features There is concern about the amount of driver-private testpmd plumbing and devargs this patch adds. The raw command count (7) is within precedent (i40e has 29, mlx5 13, ixgbe 11), but the mechanism and content are not. Error: the command logic is placed in sxe2_testpmd_lib.c, compiled into the driver library, and exposed through 14 new RTE_EXPORT_EXPERIMENTAL_SYMBOL entries (sxe2_ipsec_egress_create, sxe2_ipsec_conf_set, sxe2_flow_rule_dump, sxe2_udp_tunnel_operations, sxe2_stats_info_show, sxe2_testpmd_sched_reset, etc). No upstream driver exports symbols for its testpmd commands; all six existing drivers with testpmd integration compile their *_testpmd.c into testpmd via testpmd_sources and use internal access. These exports are vendor public API that any application can link against. The driver .so also gains application state for the commands: g_tx_session[][], g_rx_session[][], g_esp_header_offset[], g_sess_pool. SA-manager bookkeeping does not belong in a PMD. Move the logic into sxe2_testpmd.c and drop all 14 exports; at most RTE_EXPORT_INTERNAL_SYMBOL is appropriate here. Error: three commands duplicate standard testpmd functionality the driver already supports. "sxe2 flow rule dump" exists because the driver does not implement the rte_flow dev_dump op; implement the op and the standard "flow dump <port> all" works for every application. "sxe2 <port> udp_tunnel_port add|rm" duplicates "port config <port> udp_tunnel_port add|rm", which calls the udp_tunnel ops added in patch 12. "sxe2 show stats" duplicates "show port xstats"; the driver already implements xstats, and anything missing from xstats should be added there, not shown by a private formatter. Warning: the 9-subcommand ipsec suite (egress/ingress add/rm/show, session-id and esp-hdr-offset set/get, flush, stats) is an SA management application embedded in the driver. Inline crypto is exercised with examples/ipsec-secgw, as done for other inline-crypto PMDs. If interactive SA management in testpmd is needed, propose it as generic testpmd commands over rte_security so all drivers benefit. Warning: seven private devargs are added (flow-duplicate-pattern, function-flow-direct, fnav-stat-type, drv-sw-stats, high-performance-mode, sched-layer-mode, rx-low-latency) with no documentation: no Runtime Configuration section in sxe2.rst and no RTE_PMD_REGISTER_PARAM_STRING, so they are undiscoverable. Beyond documentation: flow-duplicate-pattern makes rte_flow duplicate-rule semantics vary per boot option, which is not acceptable for a standard API; fnav-stat-type and drv-sw-stats select stats sources and belong in xstats; sched-layer-mode configures TM topology that the rte_tm hierarchy built by the application should determine; high-performance-mode accepts only the value 1 and is undocumented - if the mode is safe make it the default, otherwise document the trade-off. Each surviving devarg needs documentation and a rationale for why no standard API covers it.
