On Wed, May 04, 2016 at 01:53:39PM +0000, Richardson, Bruce wrote:
>
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> > Sent: Wednesday, May 4, 2016 2:43 PM
> > To: Richardson, Bruce <bruce.richardson at intel.com>
> > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com
> > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: make struct rte_eth_dev cache
> > aligned
> >
> > On Wed, May 04, 2016 at 12:09:50PM +0100, Bruce Richardson wrote:
Snip
> > >
> > > Hi Jerin,
> >
> > Hi Bruce,
> >
> > >
> > > have you seen a performance degradation due to ethdev elements sharing
> > > a cache
> >
> > No. Not because of sharing the cache line.
> >
> > > line? I ask because, surprisingly for me, I actually see a performance
> > > regression
> >
> > I see performance degradation in PMD in my setup where independent changes
> > are causing the performance issue in PMD(~<100k). That's the reason I
> > thought making aligned cache line stuff where ever it makes sense so that
> > independent change shouldn't impact the PMD performance and this patch was
> > an initiative for the same.
> >
> > > when I apply the above patch. It's not a big change - perf reduction
> > > of <1% - but still noticable across multiple runs using testpmd. I'm
> > > using two 1x40G NICs using i40e driver, and I see ~100kpps less
> > > traffic per port after applying the patch. [CPU: Intel(R) Xeon(R) CPU
> > > E5-2699 v3 @ 2.30GHz]
> >
> > This particular patch does not have any performance degradation in my
> > setup.
> > CPU: ThunderX
>
> Ok, so I take it that this patch is performance neutral on your setup, then?
> If that's the case, can we hold off on merging it on the basis that it's not
> needed and does cause a slight regression.
OK
Can you share the base dpdk.org upstream change set where this patch
creates the slight regression? I will test it the same on IA and
ThunderX platform.
In my testpmd build, rte_eth_devices(0x0000000000751ef8) share the cache
line with inactive "notify_ops" that the reason for its not creating any
benefit.
I guess the case would have been different if its active write location.
COMMON 0x0000000000751ef0 0x8
/home/jerin/dpdk-thunderx/build/lib/librte_vhost.a(virtio-net.o)
0x0000000000751ef0 notify_ops
COMMON 0x0000000000751ef8 0x80900
/home/jerin/dpdk-thunderx/build/lib/libethdev.a(rte_ethdev.o)
0x0000000000751ef8 rte_eth_devices
Thanks,
Jerin
>
> Thanks,
> /Bruce
