[Cbe-oss-dev] Spider DMA wrongness

Benjamin Herrenschmidt benh at kernel.crashing.org
Wed Nov 8 07:38:12 EST 2006


On Tue, 2006-11-07 at 11:14 -0600, James K Lewis wrote:
> 
> Ben, 
> 
>   This is very interesting. If it will increase Spidernet performance
> without causing more bugs then we should investigate. Before
> attempting any of this though I would like more information. For
> example, are we POSITIVE we will see a performance increase by
> implementing these changes? Any idea how much? Our current driver is
> at about 700 Mbps on TX with 1500 byte packets at approx. 30% CPU
> usage. On RX, about 720 Mbps at 100% CPU (and thousands of interrupts.
> NAPI does not work on this thing because of interrupt problems). 

What about Linas patches to do interrupt mitigation with NAPI polling ?
That didn't end up working ?

>  I realize there are no guarantees in this business, however, I just
> want an idea of what to expect if these changes are made. I'm also a
> bit concerned about this big a change at this point in the schedule.  

I think the node allocations are ok as they are thanks to PCI probing
migrating us to the right node before probe. The only change in effect
that might still be interesting to implement is the split of the
descriptor chip vs. driver data. There is no way however I can predict
wether that will make any difference in preformances. It should, but
it's hard to tell without actually implementing the change.

>    Is there a way to determine if this "being on the right node"
> business is causing the performance problems in Spidernet? Linas and I
> used oprofile a while back to determine where the time was being spent
> in the driver. Is there something equivalent to help with nodes? I
> recall that using the numactl program on netperf did change the perf.
> numbers a bit. Does that help? 

As I said above, I'm starting to think we are on the right node, at
least as far as the rings are concerned. I'm not 100% certain about skbs
just yet.

Ben.





More information about the cbe-oss-dev mailing list