09/06/2022 09:09, Morten Brørup: > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Wednesday, 8 June 2022 17.27 > > > > On Wed, 8 Jun 2022 09:19:20 +0100 > > Konstantin Ananyev <konstantin.v.anan...@yandex.ru> wrote: > > > > > 07/06/2022 18:17, Stephen Hemminger пишет: > > > > The function rte_memcpy can derference past source buffer which > > > > will cause array out of bounds warnings. But there is no good > > reason > > > > to use rte_memcpy instead of memcpy in this code. Memcpy is just > > > > as fast for these small inputs, and compiler will optimize. > > > > > > > > > AFAIK, rte_memcpy() will outperform memcpy() when _size_ parameter > > > is a variable. Unfortunately that's exactly the case here. > > > So not sure it is a good change, at least without extensive perf > > testing. > > > BTW, if rte_memcpy() really access src buffer beyond it's boundaries, > > > I think that's definitely a bug that needs to be fixed. > > > > Yes and no. > > IMHO DPDK should not in the C library business, and glibc etc should be > > more optimized if necessary. > > A very big +1 to that! > > DPDK contains a lot of optimizations that really belong in the compiler > and/or C library, but weren't back then, so the clever DPDK developers put > them inside DPDK instead. > > Over time, the compilers and C libraries have improved, and many of these > manually implemented optimizations have become obsolete. They should be > cleaned up and replaced by simpler code, and the documentation about > optimizing code should be updated accordingly. > > Until that happens, we have to expect contributors to use rte_memcpy() and > other obsolete optimizations - they are only doing what the DPDK > documentation and reference code tells them. Just like application developers > are using KNI, because it is so heavily promoted in DPDK documentation. > > The DPDK community has a very high focus on the risk of performance > regressions when touching DPDK Core libraries, so a general cleaning is > probably not going to happen. Luckily, there are exceptions to every rule, > such as Georg Sauthoff's patch removing the manual loop unroll in > __rte_raw_cksum() [1], which allowed the compiler to generate something > better. > > I guess that "if it isn't broken, don't fix it" applies to DPDK Core > libraries too. ;-)
No it doesn't apply, the only limitation is the number of contributions. Feel free to propose cleanups.
