> I would prefer that rte_memcpy be laid to rest and go away.
> It never had a reason to be there.
DPDK still contains remains of hand crafted code dating back from a time where
compilers (read: the oldest compilers supported by DPDK) didn't produce
efficient code.
Rte_memcpy() is a prime exampl
On 2024-05-27 01:32, Stephen Hemminger wrote:
On Sun, 26 May 2024 16:51:52 +0200
Mattias Rönnblom wrote:
This does not change the resulting binary on almost all architectures
because x86 version of intrisics and glibc are the same, and
other architectures were using __builtin_constant_p().
Th
On 2024-05-22 05:27, Stephen Hemminger wrote:
The DPDK has a lot of unnecessary usage of rte_memcpy.
This patch set replaces cases where rte_memcpy is used with a fixed
size constant size.
Typical example is:
rte_memcpy(mac_addrs, mac.addr_bytes, RTE_ETHER_ADDR_LEN);
which can be replace
The DPDK has a lot of unnecessary usage of rte_memcpy.
This patch set replaces cases where rte_memcpy is used with a fixed
size constant size.
Typical example is:
rte_memcpy(mac_addrs, mac.addr_bytes, RTE_ETHER_ADDR_LEN);
which can be replaced with:
memcpy(mac_addrs, mac.addr_bytes
4 matches
Mail list logo