If we fail to do that, there can be superfluous calls to
ipoib_neigh_free()/ipoib_neigh_alloc() due to the following if statement in
ipoib_start_xmit():

        if (unlikely((memcmp(&neigh->dgid.raw,
                             skb->dst->neighbour->ha + 4,
                             sizeof(union ib_gid))) ||

In the case of a unicast GID, it can happen until the path is resolved and is
not so severe. In the case of a multicast address, neigh->dgid is never even
updated, so the corresponding ipoib_neigh will be destroyed and created on
every multicast packet sent.

Signed-off-by: Eli Cohen <[email protected]>
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 0bd2a4f..0005107 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -460,8 +460,6 @@ static void path_rec_completion(int status,
                        }
                        kref_get(&path->ah->ref);
                        neigh->ah = path->ah;
-                       memcpy(&neigh->dgid.raw, &path->pathrec.dgid.raw,
-                              sizeof(union ib_gid));
 
                        if (ipoib_cm_enabled(dev, neigh->neighbour)) {
                                if (!ipoib_cm_get(neigh))
@@ -878,6 +876,7 @@ struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour 
*neighbour,
        neigh->neighbour = neighbour;
        neigh->dev = dev;
        *to_ipoib_neigh(neighbour) = neigh;
+       memcpy(neigh->dgid.raw, neighbour->ha + 4, 16);
        skb_queue_head_init(&neigh->queue);
        ipoib_cm_set(neigh, NULL);
 
-- 
1.6.2.1

_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to