[PATCH v2 3/3] net/ice: do not include private headers in testpmd

[David Marchand]

On Thu, 15 Oct 2026 at 16:40, Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> On Thu, Oct 15, 2026 at 03:36:05PM +0100, Bruce Richardson wrote:
> > On Thu, Oct 15, 2026 at 03:21:04PM +0100, Anatoly Burakov wrote:
> > > Currently, the `ice_testpmd.c` file includes headers that are only
> > > available to driver itself, but should not be available to applications,
> > > including testpmd. Instead, testpmd should access them through public PMD
> > > specific API.
> > >
> > > The ice driver does not have one (even though it offers a testpmd file), so
> > > add the public PMD-specific API header, move all function definitions
> > > into that file, and get rid of driver-private includes in testpmd file.
> > >
> > > Fixes: df539aaf35cb ("net/ice: refactor flex descriptor protocol field extraction")
> > > Cc: stable at dpdk.org
> > >
> > > Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
> > > ---
> > >  doc/guides/nics/ice.rst                |  3 +
> > >  doc/guides/rel_notes/release_26_11.rst |  2 +
> > >  drivers/net/intel/ice/ice_diagnose.c   |  1 +
> > >  drivers/net/intel/ice/ice_ethdev.h     |  9 ---
> > >  drivers/net/intel/ice/ice_testpmd.c    |  7 ++-
> > >  drivers/net/intel/ice/meson.build      |  1 +
> > >  drivers/net/intel/ice/rte_pmd_ice.h    | 76 ++++++++++++++++++++++++++
> > >  7 files changed, 88 insertions(+), 11 deletions(-)
> > >  create mode 100644 drivers/net/intel/ice/rte_pmd_ice.h
> > >
> >
> > Acked-by: Bruce Richardson <bruce.richardson at intel.com>
> >
> > Given where we are, this is probably a reasonable solution. However, I'm
> > also thinking that maybe we should have a discussion as to whether testpmd
> > - which is, after all, for testing PMDs - should be limited to the public
> > APIs. Is there not a case to be made for allowing the per-driver testpmd
> > files to access the internals of the driver for testing purposes?
> >
> +techboard and others for more input and thoughts for the future.

Accessing some symbols from the internal ABI is probably ok but it is
a slippery topic.
Like the ethdev ops changes between 25.11/26.07 that triggered crashes
in app/test.


-- 
David Marchand