<html><body>
<p><tt>"Michael S. Tsirkin" <mst@mellanox.co.il> wrote on 09/26/2006 09:59:30 PM:<br>
<br>
> Quoting r. Shirley Ma <xma@us.ibm.com>:<br>
> > Subject: Re: [PATCH] IB/ipoib: NAPI<br>
> > <br>
> > We did some touch test on ehca driver, we saw performance drop somehow.<br>
> <br>
> Hmm, it seems ehca still defers the completion event to a tasklet. It always<br>
> seemed weird to me. So that could be the reason - with NAPI you now get 2<br>
> tasklet schedules, as you are actually doing part of what NAPI does,inside the<br>
> low level driver. Try ripping that out and calling the event <br>
> handler directly,<br>
> and see what it does to performance with NAPI.<br>
The reason for this ehca implementation is two ports/links shared one EQ. We are implementing multiple EQs suport for one adapter now. If that works, then we can modify the ehca code as mthca. Actually mthca has the same problem as ehca over two links on the same adapter. Two links on the same adapter performance are very bad, not scaled at all.</tt><br>
<tt> <br>
> > I strongly recommand NAPI as a configurable option in ipoib. So <br>
> customers can turn on/off based on their configurations.<br>
> <br>
> I still hope ehca NAPI performance can be fixed. But if not, maybe we should<br>
> have the low level driver set a disable_napi flag rather than have users play<br>
> with module options.<br>
> <br>
> -- <br>
> MST<br>
We have been working on this issue for some time. That's the reason we didn't post our NAPI patch. Hopefully we can fix it. If we can show NAPI performance (latency, BW, cpu utilization) are better in all cases (UP vs. SMP, one socket vs. multiple sockets, one link vs. multiple links, different message sizes, different socket sizes....) I will agree to turn on NAPI as default.</tt><br>
<br>
Thanks<br>
Shirley Ma<br>
IBM Linux Technology Center<br>
15300 SW Koll Parkway<br>
Beaverton, OR 97006-6063<br>
Phone(Fax): (503) 578-7638</body></html>