[openib-general] Re: Re: [PATCH] (fixed) reduce qp locking on cq poll

Michael S. Tsirkin mst at mellanox.co.il
Wed Jan 26 12:13:22 PST 2005


Quoting r. Grant Grundler <iod00d at hp.com>:
> Subject: Re: Re: [PATCH] (fixed) reduce qp locking on cq poll
> 
> On Wed, Jan 26, 2005 at 09:37:49PM +0200, Michael S. Tsirkin wrote:
> > Quoting r. Grant Grundler <iod00d at hp.com>:
> > > Subject: Re: Re: [PATCH] (fixed) reduce qp locking on cq poll
> > > 
> > > On Wed, Jan 26, 2005 at 07:19:02PM +0200, Michael S. Tsirkin wrote:
> > > > > I'm a little worried that you see no improvement from this patch -- it
> > > > > doesn't seem like fast hardware should be required.
> > > 
> > > I was wondering the same thing. Why is fast HW required?
> > 
> > See below.
> 
> Sorry - I didn't see the answer "below".
> Can you be more specific?

Its not the speed of hardware, my problem is the variations.

> > > Can you quantify what you mean by "wild variations" and "big wins"?
> > 
> > Goes up or down up to 3% on a bad day. Anything less is noise for me.
> 
> Ok - I expect repeatability to be < 1% and ideally < 0.1%.
> On a private LAN at least. :^)
> 
> > > Have you tried pinning the test processes to a particular CPU
> > > with taskset?
> > 
> > No. Why will this help?
> 
> cacheline ping-ponging will be the same between test runs.
> 
> Did you see the difference in IPoIB numbers that I posted
> earlier where I pegged the test processes to the same CPU
> taking interrupts or a different CPU? 
> 
> For netperf, this was especially important for the system
> running "netserver" process.
> 
> grant

No - link?

-- 
I dont speak for Mellanox



More information about the general mailing list