<br><font size=2><tt>Roland Dreier <rdreier@cisco.com> wrote on 04/18/2006
03:01:57 PM:<br>
<br>
>     Shirley> After completion handler receives the notification,
don't<br>
>     Shirley> poll the CQ right away, and wait for more
WIKIs in<br>
>     Shirley> CQ. That way can reduce the CQ lock overhead.<br>
> <br>
> That's interesting... it makes sense, and it argues in favor of<br>
> deferring CQ polling to a kernel thread.  Of course this will
hurt<br>
> ping-pong latency.  Maybe it's better to just implement NAPI
though...<br>
</tt></font>
<br><font size=2><tt>Let's try difference implementations to see the difference.</tt></font>
<br><font size=2><tt><br>
>     Shirley> I found that there is some problem to increase
the NUM_WC<br>
>     Shirley> on recv. It hurts the performance lots.
Do you have any<br>
>     Shirley> clue?<br>
> <br>
> Is this on ehca or mthca?  I couldn't explain it on mthca, but
on ehca<br>
> maybe there's a bug in generating CQ events ??<br>
> <br>
>  - R.<br>
</tt></font>
<br><font size=2><tt>It's on mthca. If you are interested. I can submit
a test patch for your experimental.</tt></font>
<br>
<br><font size=2><tt>Thanks</tt></font>
<br><font size=2 face="sans-serif">Shirley Ma<br>
IBM Linux Technology Center<br>
15300 SW Koll Parkway<br>
Beaverton, OR 97006-6063<br>
Phone(Fax): (503) 578-7638<br>
</font>