<br><font size=2><tt>Roland Dreier <rdreier@cisco.com> wrote on 05/23/2006
09:09:05 AM:<br>
<br>
> Did you send the other 6 patches in this series?<br>
Yes, I am splitting these patches.</tt></font>
<br><font size=2><tt><br>
> I was waiting to comment until I had all the patches, but there is
one<br>
> really bad thing here:<br>
> <br>
>  > +       IPOIB_NUM_SEND_WC    
    = 32,<br>
> <br>
>  > +void ipoib_ib_send_completion(struct ib_cq *cq, void *dev_ptr)<br>
>  > +{<br>
>  > +       struct net_device *dev = (struct
net_device *) dev_ptr;<br>
>  > +       struct ipoib_dev_priv *priv = netdev_priv(dev);<br>
>  > +       struct ib_wc ibwc[IPOIB_NUM_SEND_WC];<br>
> <br>
> If I'm doing the math correctly, this function now uses more than
2K<br>
> of stack, which is of course unacceptable.<br>
> <br>
> I don't think there's any way around keeping the wc array in the<br>
> ipoib_dev_priv structure.<br>
> <br>
>  - R.<br>
</tt></font>
<br><font size=2><tt>The stack is 4k, not 8K anymore. I think we can still
use IPOIB_NUM_SEND_WC as 4. I modified mthca_XXX_post_send to remove lock
totally before(since sender is exclusive), and found that lock didn't impact
performance too much.</tt></font>
<br><font size=2 face="sans-serif"><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<br>
<br>
</font>
<br>
<br>