<br><font size=2><tt>Roland,</tt></font>
<br>
<br><font size=2><tt>Roland Dreier <rdreier@cisco.com> wrote on 05/24/2006
03:01:01 PM:<br>
>     Shirley> Compared to have a single thread handling
AH, I don't<br>
>     Shirley> think this atomic operation is expensive.<br>
> <br>
> But freeing AHs is something that happens infrequently and can be
done<br>
> asynchronously.  You're replacing that cost with two atomic operations<br>
> per send packet!<br>
</tt></font>
<br><font size=2><tt>No, actually it didn't free during sending during
my test.</tt></font>
<br><font size=2><tt><br>
>     Shirley> It is true for unicast, it has a reference
count before<br>
>     Shirley> ipoib_send(). I need to look at multicast.<br>
> <br>
> But can you guarantee that the AH stays around until after the send<br>
> completes (which could be an arbitrarily long delay)?<br>
> <br>
>  - R.</tt></font>
<br>
<br><font size=2 face="sans-serif">I checked negih_add_path(), for unicast
it is true always. See code below.</font>
<br>
<br><font size=2 face="sans-serif">static void neigh_add_path(..)</font>
<br><font size=2 face="sans-serif">{</font>
<br><font size=2 face="sans-serif">...</font>
<br><font size=2 face="sans-serif">        if (path->ah)
{</font>
<br><font size=2 face="sans-serif">           
    kref_get(&path->ah->ref);</font>
<br><font size=2 face="sans-serif">           
    neigh->ah = path->ah;</font>
<br><font size=2 face="sans-serif">         
  ipoib_send(dev, skb, path->ah...        </font>
<br><font size=2 face="sans-serif">}        </font>
<br><font size=2 face="sans-serif"><br>
Please correct me if I am wrong.</font>
<br>
<br><font size=2 face="sans-serif">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><font size=2><tt><br>
</tt></font>