Breaking regression. Rejecting static flow id: 0 aborts daqiri_init() for 14 shipped configs that use it — incl. the canonical daqiri_bench_raw_tx_rx.yaml:50, every reorder config (daqiri_bench_raw_tx_rx_reorder_seq_1024.yaml:61, …), HDS, 4q, spark, gds_write, pcap_writer, and the sw_loopback_reorder smoke test. reserve_static_flow_ids() runs early in initialize(), so these fail before EAL/queue setup. Either keep 0 valid for static flows (reserve 0 only in the dynamic allocator; treat static 0 as no-mark) or migrate every static flows[].id and the matching reorder_configs[].flow_ids and the walkthrough docs in this same PR. As written, existing users break on upgrade.

configure_flow_api_for_port() runs for every port unconditionally (dynamic_flow_capacity_ defaults to 1024, no off switch), so every existing DPDK config now opts the port into the async template engine via rte_flow_configure() — even static-only configs that never add a dynamic flow. We run mlx5 in HWS (dv_flow_en=2), yet the jump rule, static flows (add_flow), and drop_all_traffic still use synchronous rte_flow_create. Mixing the configured template engine with non-template rte_flow_create on the same mlx5 port is version/PMD-sensitive (group-namespace + post-configure create constraints), and the example is dynamic-only so static+dynamic mixing is untested. Suggest gating behind an explicit opt-in (e.g. dynamic_flow_capacity: 0 ⇒ disabled, default off) so static-only configs are unaffected, and validating a mixed config on CX7.

Destroys every dynamic flow with synchronous rte_flow_destroy, ignoring entry.backend. TEMPLATE-backed flows were created via rte_flow_async_create and must be torn down with rte_flow_async_destroy + rte_flow_push/rte_flow_pull; rte_flow_destroy on a template-table handle isn't supported on mlx5 and will likely fail, which then makes the rte_flow_template_table_destroy below fail (table still owns flows). Branch on entry.backend and drain async destroys before destroying the table. Shutdown-only; bites when ACTIVE template flows exist at exit.

Entry is erased even when rte_flow_destroy failed above. The caller gets a failed DELETE completion, but the rule may still be installed in HW and is now untracked — it can't be retried or cleaned up. Keep the entry (ACTIVE) on failure. Same pattern in poll_dpdk_flow_completions_locked (a failed RTE_FLOW_OP_* destroy still erases) and in the template add paths (push failure abandons an already-enqueued rte_flow_async_create handle). Suggest a consistent "only forget on confirmed success" rule.

allocate_dynamic_flow_id() only increments and never reclaims ids freed by delete. The id is written as the HW MARK (mark->id = flow_id, read back via mbuf->hash.fdir.hi), and mlx5 caps the usable FDIR mark well below uint32_t (~24 bits, minus reserved). For an add/delete-churn feature, a long-running control plane climbs past the mark ceiling (and table nb_flows) long before the counter wraps. Recommend recycling ids on delete completion and validating against the HW mark limit at allocation.

Delete rejects anything not ACTIVE, but a TEMPLATE flow stays ADDING until its add completion is drained by poll_flow_op. So add-then-immediate-delete (before polling the add) returns INVALID_PARAMETER. The example happens to wait for the add completion first — please document this ordering requirement so callers don't hit a surprising rejection.

static mask structs are a needless reentrancy/thread-safety smell — they only work because rte_flow_pattern_template_create deep-copies immediately. Plain locals are clearer and safe.

This says unmatched packets are dropped under flow_isolation: true, but docs/tutorials/configuration-walkthrough.md item 19 says they're delegated back to the Linux kernel (the rte_flow_isolate semantics). This PR edits this passage and adds guidance that leans on the drop behavior, so the two docs should be reconciled to whatever the port actually does on this HW. (No code change in this PR alters the isolation path — rte_flow_isolate(port,1) is unchanged — so this is a doc-consistency fix, not a behavior change.)

FlowMatchType::NORMAL → IPV4_UDP (and pybind value "NORMAL"→"IPV4_UDP") is a breaking API rename for any external caller referencing the old name. No in-repo refs remain, but please call it out in the PR description / release notes.