> From: Morten Brørup > Sent: Friday, 8 May 2026 11.16 > > > From: Burakov, Anatoly [mailto:[email protected]] > > 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 > > <[email protected]> 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- > [email protected]/ > [2]: > https://github.com/ovsrobot/dpdk/actions/runs/25104438552/job/749682184 > 20 [3]: https://patchwork.dpdk.org/project/dpdk/patch/[email protected]/ > > -Morten
