On Thu, 18 Jun 2026 10:44:35 -0400 Dawid Wesierski <[email protected]> wrote:
> From: Marek Kasiewicz <[email protected]> > > This series introduces several improvements to Intel iavf and ice > drivers, including a new ethdev API for header split mbuf callbacks, > increased ring descriptors, and improved PTP timestamping. > > Marek Kasiewicz (7): > ethdev: add header split mbuf callback API > net/iavf: increase max ring descriptors to hardware limit > net/iavf: allow runtime queue rate limit configuration > net/ice/base: reduce default scheduler burst size > net/ice: timestamp all received packets when PTP is enabled > net/iavf: disable runtime queue setup capability > net/intel: support header split mbuf callback > > drivers/net/intel/common/rx.h | 2 + > drivers/net/intel/iavf/iavf_ethdev.c | 3 -- > drivers/net/intel/iavf/iavf_rxtx.h | 2 +- > drivers/net/intel/iavf/iavf_tm.c | 11 ++-- > drivers/net/intel/ice/base/ice_type.h | 2 +- > drivers/net/intel/ice/ice_ethdev.c | 1 + > drivers/net/intel/ice/ice_rxtx.c | 72 ++++++++++++++++++++++++--- > drivers/net/intel/ice/ice_rxtx.h | 2 + > lib/ethdev/ethdev_driver.h | 15 +++++++ > lib/ethdev/rte_ethdev.c | 51 ++++++++++++++++++++++ > lib/ethdev/rte_ethdev.h | 7 +++ > 11 files changed, 153 insertions(+), 15 deletions(-) > This looks interesting but I don't understand the motivation or use case for the new code. There is no documentation, examples or test integration. At this point the patch is in pure RFC state. More wordy answer from AI... Documentation and motivation This adds a new public ethdev RX mechanism but ships no prose rationale, no documentation, and no worked example. For a new API the series needs to make the case before the code can be evaluated. Missing documentation: - No prog_guide section. A new RX model -- header split where the application supplies the payload buffer -- needs a write-up (e.g. in doc/guides/prog_guide) covering the buffer-lifetime contract, the IOVA/headroom semantics, which offloads must be enabled (RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT), and what happens on a PMD that does not implement the hook. - No example or testpmd integration. There is no end-to-end flow a reviewer can read or run: register the callback, supply buffers, receive, consume, recycle. Without one there is no demonstrated use case and no way to validate the design (the mempool-corruption and headroom issues in 7/7 would likely have surfaced in a working example). Missing motivation: - The actual use case is not named. "Zero-copy RX into mapped frame buffers with known IOVA" describes a mechanism, not a user. Who needs this -- an AF_XDP-style external umem, a GPU/DMA target (gpudev), something else? State it. - The benefit is unquantified. The claim is avoiding "an extra memcpy from the mempool mbuf," but the patch replaces that with a per-allocation indirect callback on the Rx fast path (ice_recv_pkts, ice_rx_alloc_bufs). The rationale should show the memcpy actually exists in the path being optimized and that the indirect call per buffer is a net win. - It does not explain why existing mechanisms are insufficient. DPDK already lets an application own payload memory via rte_pktmbuf_attach_extbuf() and via external-buffer mempools (pinned external memory passed to the Rx mempool). The series must argue why a new callback API is needed instead of those -- this is the same alternative raised against the 7/7 implementation, so the motivation and the correctness fix point at the same question. - Constraints are undocumented: PMD support scope, fast-path threading and reentrancy of the callback, and interaction with the buffer-split configuration. Until there is a documented model and at least one example showing the buffer lifecycle, it is hard to tell whether the callback API is the right shape -- or whether attach_extbuf / an external-mempool already covers the use case.
