On Fri, May 08, 2026 at 12:16:01PM +0200, Morten Brørup wrote: > > 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. > Actually, I'm more wondering if we really need to use rte_memcpy in our drivers. Any use of memcpy is likely on the control path, and not performance critical enough to warrant use of anything but the built-in memcpy.
/Bruce
