[PATCH 1/2] net/iavf: use mbuf packet type instead of dynfield for LLDP

[Loftus, Ciara]

> Subject: Re: [PATCH 1/2] net/iavf: use mbuf packet type instead of dynfield for
> LLDP
> 
> On Mon, Feb 09, 2026 at 03:20:48PM +0000, Ciara Loftus wrote:
> > Instead of using a dynamic mbuf field to flag a packet as LLDP, instead
> > utilise the mbuf packet type field as the identifier instead. If the
> > type is RTE_PTYPE_L2_ETHER_LLDP the packet is identified as LLDP. This
> > approach is preferable because the use of dynamic mbuf fields should be
> > reserved for features that are not easily implemented using the existing
> > mbuf infrastructure. No negative performance impacts were observed with
> > the new approach.
> >
> > Signed-off-by: Ciara Loftus <ciara.loftus at intel.com>
> 
> For ABI compatibility, though, I think we need to keep the old method of
> identifying LLDP packets there too. While I completely agree that using
> packet types is the better approach, we need to go through a deprecation
> process for the old dynamic field method, though.

I will submit a v2 supporting both the dynfield and ptype approach, and a
deprecation notice flagging the future removal of the dynfield.

> 
> > ---
> >  doc/guides/nics/intel_vf.rst           | 16 +++++++++-------
> >  doc/guides/rel_notes/release_26_03.rst |  1 +
> >  drivers/net/intel/iavf/iavf_ethdev.c   | 13 ++++++++-----
> >  drivers/net/intel/iavf/iavf_rxtx.c     |  3 +--
> >  drivers/net/intel/iavf/iavf_rxtx.h     |  8 +++-----
> >  drivers/net/intel/iavf/iavf_testpmd.c  | 20 +++++---------------
> >  drivers/net/intel/iavf/rte_pmd_iavf.h  | 10 ++++++++++
> >  7 files changed, 37 insertions(+), 34 deletions(-)
> >
> > diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
> > index bc600e4b58..197918b2e8 100644
> > --- a/doc/guides/nics/intel_vf.rst
> > +++ b/doc/guides/nics/intel_vf.rst
> > @@ -668,19 +668,21 @@ Inline IPsec Support
> >  Diagnostic Utilities
> >  --------------------
> >
> 
> <snip>
> >
> 
> > +RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_pmd_iavf_enable_tx_lldp,
> 26.03)
> > +void
> > +rte_pmd_iavf_enable_tx_lldp(bool enable)
> > +{
> > +	iavf_tx_lldp_enabled = enable;
> > +}
> > +
> Rather than a private function, this looks something that should be a
> feature flag or capability somewhere, e.g. like TSO.

I think that would be a neater solution for iavf, but I
can't find any evidence of any other driver requiring this
sort of explicit enabling of LLDP as a feature. So it would
be hard to justify adding such a feature flag/capability
when it looks like there might only be one driver to use it.
I will consider this some more.
Since we are keeping the dynfield implementation for now,
registering the dynfield is equivalent to enabling the
feature so we don't need an API like this in the v2. When we
eventually remove the dynfield I will try to find a better
solution for enabling the feature, that isn't a private
function.