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

Bruce Richardson <[email protected]>
Newsgroups org.dpdk.dev
Message-ID <[email protected]>
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 <[email protected]>
> > Signed-off-by: Dawid Wesierski <[email protected]>
> > ---
> Acked-by: Bruce Richardson <[email protected]>
> 
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.