Re: [PATCH v2 0/7] Intel network drivers enhancements

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 18 Jun 2026 10:44:35 -0400
Dawid Wesierski <dawid.wesierski@intel.com> wrote:

> From: Marek Kasiewicz <marek.kasiewicz@intel.com>
> 
> 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.