RE: [PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Morten Brørup
> Sent: Friday, 8 May 2026 11.16
> 
> > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > Sent: Thursday, 7 May 2026 10.09
> >
> > On 5/6/2026 5:58 PM, David Marchand wrote:
> > > On Wed, 6 May 2026 at 16:07, Anatoly Burakov
> > <anatoly.burakov@intel.com> wrote:
> > >>
> > >
> > > - all those virtchnl list struct have the same elems[1] issue.
> > > Kernel side did some cleanups some time ago, maybe time for DPDK to
> > do
> > > the same...?
> > >
> >
> > Yes, it is indeed time to do the same, but not as part of this
> > patchset,
> > and not before the base driver code is updated to do the same. There
> is
> > some background work happening on that front already, but there are a
> > lot of dependencies and moving parts, so we can't just change this
> > willy
> > nilly.
> 
> Is there a timeline for this fix?
> 
> With the performance improved rte_memcpy() patch [1], one of the CI
> compilers complains about buffer overflows when writing beyond these
> undersize arrays [2].
> And I'd like to see the performance improved rte_memcpy() merged in
> 26.07.

With v10 of the rte_memcpy() patch [3], I have reverted the removal of the workaround that ignores stringop-overflow warnings in rte_memcpy(), so the patch doesn't depend on fixing the drivers.

Please take note to remove the workaround from rte_memcpy() when the flex array issue in the drivers - using elems[1] instead of elems[] - has been fixed.
Not ignoring buffer overflows in rte_memcpy() might help reveal bugs elsewhere.

Alternatively, move the workaround from rte_memcpy.h to the driver code requiring the workaround.

> 
> [1]:
> https://patchwork.dpdk.org/project/dpdk/patch/20260429103548.220354-1-
> mb@smartsharesystems.com/
> [2]:
> https://github.com/ovsrobot/dpdk/actions/runs/25104438552/job/749682184
> 20

[3]: https://patchwork.dpdk.org/project/dpdk/patch/20260508095827.53587-1-mb@smartsharesystems.com/

> 
> -Morten