Hi Roland,
Looking on ipoib_start_xmit, it seems that both the check that comes to handle
a gratitious
ARP (ie a difference between the remote GID as kept in the ipoib_neigh to the
one present in
the network stack neighbour) and the check that comes to handle a situation
where we attempt to
xmit an ipoib_neigh created by another ipoib device (ie following a bonding
failover) -
does not come into play for the connected mode neighbours.
Isn't it a bug, or I miss something?
Or.
+static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+ struct ipoib_neigh *neigh;
+ unsigned long flags;
+
...
+ if (likely(skb->dst && skb->dst->neighbour)) {
...
+ neigh = *to_ipoib_neigh(skb->dst->neighbour);
+
+ if (ipoib_cm_get(neigh)) {
+ if (ipoib_cm_up(neigh)) {
+ ipoib_cm_send(dev, skb, ipoib_cm_get(neigh));
+ goto out;
+ }
+ } else if (neigh->ah) {
+ if (unlikely((memcmp(&neigh->dgid.raw,
+ skb->dst->neighbour->ha + 4,
+ sizeof(union ib_gid))) ||
+ (neigh->dev != dev))) {
any reason not to apply these two checks on connected mode neighbours?
+ spin_lock(&priv->lock);
...
+ ipoib_send(dev, skb, neigh->ah,
IPOIB_QPN(skb->dst->neighbour->ha));
+ goto out;
+ }
_______________________________________________
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
