[PATCH v6 2/2] net/iavf: disable runtime queue setup during queue rate limiting

Bruce Richardson bruce.richardson at intel.com
Thu Jul 23 12:29:01 CEST 2026


On Mon, Jul 13, 2026 at 11:09:40AM +0100, Bruce Richardson wrote:
> On Mon, Jul 13, 2026 at 05:42:58AM -0400, Dawid Wesierski wrote:
> > 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.
> > 
> > Rather than gating this behind a devarg that an application would have
> > to know to set (and could just as easily avoid triggering the race by
> > not calling rte_eth_{rx,tx}_queue_setup() on a running port), stop
> > advertising RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP and
> > RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP as soon as the application
> > commits a per-queue bandwidth rte_tm hierarchy, i.e. as soon as the
> > condition that causes the race actually exists. iavf_dev_info_get() is
> > re-queried by the ethdev layer on every rx/tx_queue_setup() call, so
> > this is enough for the generic layer to start rejecting runtime queue
> > (re)configuration with -EBUSY once queue rate limiting is active, and
> > to automatically allow it again once the rte_tm hierarchy is torn
> > down.
> > 
> > vf->qtc_map, already used elsewhere to look up a queue's TC mapping,
> > is repurposed as the "queue bandwidth committed" signal since it's set
> > by iavf_hierarchy_commit() exactly when a per-queue bandwidth mapping
> > has been pushed to the PF, regardless of whether the port was stopped
> > at the time. Fix two related issues found while making it load-bearing
> > for this check:
> > 
> > - iavf_hierarchy_commit() replaced vf->qtc_map on every successful
> >   commit without freeing the previous allocation, leaking memory.
> > - vf->qtc_map was never released on VF teardown, so
> >   iavf_uninit_vf()/iavf_init_vf() (e.g. across a VF reset) could leave
> >   a stale pointer referencing freed unrelated memory, and the runtime
> >   queue setup capability would never be re-advertised after a reset.
> > 
> > Both are fixed by freeing vf->qtc_map before replacing it in
> > iavf_hierarchy_commit(), and freeing and clearing it in
> > iavf_uninit_vf().
> > 
> > Signed-off-by: Marek Kasiewicz <marek.kasiewicz at intel.com>
> > Signed-off-by: Dawid Wesierski <dawid.wesierski at intel.com>
> > ---
> Acked-by: Bruce Richardson <bruce.richardson at intel.com>
> 
> Unfortunately, since we are now past RC3 for 26.07, I'm not going to take
> this change for this release. [For RC4, we limit changes to critical fixes
> and doc changes, so as to avoid last-minute issues]. I'm doing to mark this
> as deferred and will take it in 26.11 whenever my tree opens for patches
> for that release.
> 
Changed release note update to target the 26.11 one and applied patch to
next-net-intel.

Thanks,
/Bruce


More information about the dev mailing list