[dpdk-dev] [PATCH 2/2] mbuf: make sure userdata is initialized

2016-02-03 Thread Olivier MATZ
Hi, On 07/10/2015 05:43 PM, Stephen Hemminger wrote: > On Fri, 10 Jul 2015 10:32:17 +0100 > Bruce Richardson wrote: > >> On Thu, Jul 09, 2015 at 04:37:48PM -0700, Stephen Hemminger wrote: >>> From: Stephen Hemminger >>> >>> For applications that use m->userdata the initialization can >>> be a si

[dpdk-dev] [PATCH 2/2] mbuf: make sure userdata is initialized

2015-07-15 Thread Olivier MATZ
On 07/10/2015 05:43 PM, Stephen Hemminger wrote: > On Fri, 10 Jul 2015 10:32:17 +0100 > Bruce Richardson wrote: > >> On Thu, Jul 09, 2015 at 04:37:48PM -0700, Stephen Hemminger wrote: >>> From: Stephen Hemminger >>> >>> For applications that use m->userdata the initialization can >>> be a signfic

[dpdk-dev] [PATCH 2/2] mbuf: make sure userdata is initialized

2015-07-10 Thread Bruce Richardson
On Thu, Jul 09, 2015 at 04:37:48PM -0700, Stephen Hemminger wrote: > From: Stephen Hemminger > > For applications that use m->userdata the initialization can > be a signficant (10%) performance penalty. > > Rather than taking the cache penalty of initializing userdata > in the receive handling,

[dpdk-dev] [PATCH 2/2] mbuf: make sure userdata is initialized

2015-07-10 Thread Stephen Hemminger
On Fri, 10 Jul 2015 10:32:17 +0100 Bruce Richardson wrote: > On Thu, Jul 09, 2015 at 04:37:48PM -0700, Stephen Hemminger wrote: > > From: Stephen Hemminger > > > > For applications that use m->userdata the initialization can > > be a signficant (10%) performance penalty. > > > > Rather than ta

[dpdk-dev] [PATCH 2/2] mbuf: make sure userdata is initialized

2015-07-09 Thread Stephen Hemminger
From: Stephen Hemminger For applications that use m->userdata the initialization can be a signficant (10%) performance penalty. Rather than taking the cache penalty of initializing userdata in the receive handling, do it in the place where mbuf is already cache hot and being setup. Signed-off-b