Re: [dpdk-dev] [PATCH] mbuf: replace c memcpy() code semantics with optimized rte_memcpy()

2020-07-28 Thread Stephen Hemminger
On Thu, 23 Jul 2020 12:02:40 +0500 Sarosh Arif wrote: > Since rte_memcpy is more optimized it should be used instead of memcpy > > Signed-off-by: Sarosh Arif The part in pkmbuf_pool_init is not performance critical. The layout of rte_mbuf_dynfield is sub optimal. struct rte_mbuf_dynfield {

Re: [dpdk-dev] [PATCH] mbuf: replace c memcpy() code semantics with optimized rte_memcpy()

2020-07-28 Thread Olivier Matz
Hi Sarosh, On Tue, Jul 28, 2020 at 06:30:46PM +0500, Sarosh Arif wrote: > Hello, > The following things made me think that rte_memcpy() is more optimized > than memcpy(): > 1. dpdk documentation recommends to use rte_memcpy() instead of memcpy(): > https://doc.dpdk.org/guides/prog_guide/writin

Re: [dpdk-dev] [PATCH] mbuf: replace c memcpy() code semantics with optimized rte_memcpy()

2020-07-28 Thread Sarosh Arif
Hello, The following things made me think that rte_memcpy() is more optimized than memcpy(): 1. dpdk documentation recommends to use rte_memcpy() instead of memcpy(): https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.html 2. Here some benchmarks are available: https://software.

Re: [dpdk-dev] [PATCH] mbuf: replace c memcpy() code semantics with optimized rte_memcpy()

2020-07-23 Thread Stephen Hemminger
On Thu, 23 Jul 2020 12:02:40 +0500 Sarosh Arif wrote: > Since rte_memcpy is more optimized it should be used instead of memcpy > > Signed-off-by: Sarosh Arif Really did you measure this. For fixed size structures, compiler can inline memcpy small set of instructions.

[dpdk-dev] [PATCH] mbuf: replace c memcpy() code semantics with optimized rte_memcpy()

2020-07-23 Thread Sarosh Arif
Since rte_memcpy is more optimized it should be used instead of memcpy Signed-off-by: Sarosh Arif --- lib/librte_mbuf/rte_mbuf.c | 2 +- lib/librte_mbuf/rte_mbuf.h | 3 ++- lib/librte_mbuf/rte_mbuf_dyn.c | 8 +--- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/lib/lib

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-06-24 Thread Olivier Matz
Hi Dave, On 06/24/2016 05:56 PM, Hunt, David wrote: > Hi Jerin, > > I just ran a couple of tests on this patch on the latest master head on > a couple of machines. An older quad socket E5-4650 and a quad socket > E5-2699 v3 > > E5-4650: > I'm seeing a gain of 2% for un-cached tests and a gain of

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-06-24 Thread Hunt, David
Hi Jerin, I just ran a couple of tests on this patch on the latest master head on a couple of machines. An older quad socket E5-4650 and a quad socket E5-2699 v3 E5-4650: I'm seeing a gain of 2% for un-cached tests and a gain of 9% on the cached tests. E5-2699 v3: I'm seeing a loss of 0.1% fo

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-30 Thread Olivier Matz
On 05/27/2016 05:05 PM, Thomas Monjalon wrote: > 2016-05-27 17:12, Jerin Jacob: >> IMHO, I think we should have means to abstract this _logical_ changes >> under conditional compilation flags and any arch/platform can choose >> to select what it suites better for that arch/platform. >> >> We may

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-27 Thread Jerin Jacob
On Fri, May 27, 2016 at 11:24:57AM +0100, Hunt, David wrote: > > > On 5/24/2016 4:17 PM, Jerin Jacob wrote: > > On Tue, May 24, 2016 at 04:59:47PM +0200, Olivier Matz wrote: > > > > > Are you seeing some performance improvement by using rte_memcpy()? > > Yes, In some case, In default case, It wa

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-27 Thread Thomas Monjalon
2016-05-27 17:12, Jerin Jacob: > IMHO, I think we should have means to abstract this _logical_ changes > under conditional compilation flags and any arch/platform can choose > to select what it suites better for that arch/platform. > > We may NOT need to have frequent patches to select the specifi

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-27 Thread Hunt, David
On 5/27/2016 11:24 AM, Hunt, David wrote: > > > On 5/24/2016 4:17 PM, Jerin Jacob wrote: >> On Tue, May 24, 2016 at 04:59:47PM +0200, Olivier Matz wrote: >> >>> Are you seeing some performance improvement by using rte_memcpy()? >> Yes, In some case, In default case, It was replaced with memcpy by

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-27 Thread Hunt, David
On 5/24/2016 4:17 PM, Jerin Jacob wrote: > On Tue, May 24, 2016 at 04:59:47PM +0200, Olivier Matz wrote: > >> Are you seeing some performance improvement by using rte_memcpy()? > Yes, In some case, In default case, It was replaced with memcpy by the > compiler itself(gcc 5.3). But when I tried ex

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-24 Thread Jerin Jacob
On Tue, May 24, 2016 at 04:59:47PM +0200, Olivier Matz wrote: > Hi Jerin, > > > On 05/24/2016 04:50 PM, Jerin Jacob wrote: > > Signed-off-by: Jerin Jacob > > --- > > lib/librte_mempool/rte_mempool.h | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/lib/librte_

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-24 Thread Jerin Jacob
Signed-off-by: Jerin Jacob --- lib/librte_mempool/rte_mempool.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h index ed2c110..ebe399a 100644 --- a/lib/librte_mempool/rte_mempool.h +++ b/lib/librte_mempoo

[dpdk-dev] [PATCH] mbuf: replace c memcpy code semantics with optimized rte_memcpy

2016-05-24 Thread Olivier Matz
Hi Jerin, On 05/24/2016 04:50 PM, Jerin Jacob wrote: > Signed-off-by: Jerin Jacob > --- > lib/librte_mempool/rte_mempool.h | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_mempool/rte_mempool.h > b/lib/librte_mempool/rte_mempool.h > index ed2c110..ebe39