[openib-general] Unicast ARP

[Roland Dreier]

    Hal> Is this restricted to LID changes or apply more generally to
    Hal> hardware address (GID and/or QPN) changes ? (I had seen
    Hal> something similar when the QPN changed; ARP timeout/retries
    Hal> are needed prior to connectivity being restored).

Just LID changes.  If GID or QPN changes, then the HW address is
different and the kernel neighbour code can notice.  It's just like an
IP address moving to a different MAC on ethernet: either the old ARP
entry has to time out, or the interface with the new address has to
send a gratuitous ARP.

    Hal> Is this the PathRecord lookup for unicast GID of destination
    Hal> ? Is the path record (info) cached ?

Yes, path lookup for unicast GID.  It's not cached, which is what
causes the issue: the ARP will get a reply and so the kernel will
believe the neighbour is still valid, even though it has an obsolete
path in it.

    Ido> then ARP is sent to this address, and when ARP response
    Ido> arrives back, ARP cache is not updated with the new path.

    Hal> Do you mean hardware address here (GID + QPN) ?

No, he meant path (LID, SL, etc)

 - R.