On Tue, Jun 30, 2026 at 08:06:55AM -0400, Dawid Wesierski wrote: > From: Marek Kasiewicz <[email protected]> > > Remove the advertisement of RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP > and RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP capabilities from the > iavf VF driver. > > Runtime queue setup on E810 VFs causes queue state corruption when > queues are dynamically reconfigured while the hardware rate limiter > is actively pacing TX queues. Queue configuration messages to the PF > via virtchnl can race with ongoing TX operations, leading to undefined > behavior. > > By not advertising these capabilities, all queues are configured at > port start and remain stable throughout the port lifecycle. > > Signed-off-by: Marek Kasiewicz <[email protected]> > Signed-off-by: Dawid Wesierski <[email protected]> > --- > doc/guides/nics/intel_vf.rst | 9 +++++++++ > doc/guides/rel_notes/release_26_07.rst | 2 ++ > drivers/net/intel/iavf/iavf.h | 1 + > drivers/net/intel/iavf/iavf_ethdev.c | 22 ++++++++++++++++++---- > 4 files changed, 30 insertions(+), 4 deletions(-) > > diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst > index e010f852cf..86878330f2 100644 > --- a/doc/guides/nics/intel_vf.rst > +++ b/doc/guides/nics/intel_vf.rst > @@ -131,6 +131,15 @@ IAVF PMD parameters > * ``segment``: Check number of mbuf segments does not exceed HW limits. > * ``offload``: Check for use of an unsupported offload flag. > > +``no_runtime_queue_setup`` > + Runtime (post-start) Rx/Tx queue setup can race with the hardware Tx rate > + limiter on E810 VFs and corrupt queue state. > + It is advertised by default. > + Applications that pace queues through the traffic manager can opt out > + of advertising the runtime queue setup capability > + by setting ``no_runtime_queue_setup`` to 1, > + for example, ``-a 18:01.0,no_runtime_queue_setup=1``. > +
Do we really need a commandline arg for this? If it's known enough to have the extra arg passed at device init, is it not also known enough to have the app not do dynamic reconfiguration in the first place? Alternatively, if the user configures packet pacing through rte_tm, can we not at that point adjust the driver to disallow runtime config by returning -ENOTSUP when reconfig is attempted, and no longer advertising the capabilities? Runtime configuration, whether with or without user interaction, should be preferred over devargs whenever possible. /Bruce
