| To: | hadi@xxxxxxxxxx |
|---|---|
| Subject: | Re: Advice needed on IP-over-InfiniBand driver |
| From: | Roland Dreier <roland@xxxxxxxxxxx> |
| Date: | Sun, 19 Sep 2004 21:49:25 -0700 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <1095628759.1049.22.camel@xxxxxxxxxxxxxxxx> (jamal's message of "19 Sep 2004 17:19:19 -0400") |
| References: | <52fz5esxx6.fsf@xxxxxxxxxxx> <20040919140133.60ea3fb3.davem@xxxxxxxxxxxxx> <1095628759.1049.22.camel@xxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) |
jamal> Probably just easier to have his own private tables holding
jamal> reference to neighbor entries instead of polluting the
jamal> neighbor tables. Listens to ARP events - on state
jamal> transition to/from reachable state he queries his remote
jamal> manager.
This does seem neater, but I don't know how to implement it. How does
one hook into ARP events?
jamal> Curious though if ARP still works even when that "path"
jamal> thing hasnt been resolved.
ARP works because we can send broadcasts even without a path to a
specific destination. (I'm leaving out the details of how IP
broadcast gets mapped to InfiniBand multicast) When the system with
the IP we're looking for receives a broadcast ARP, it can use the HW
address in the ARP request to look up a path, so it can send an ARP
reply.
Thanks,
Roland
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Advice needed on IP-over-InfiniBand driver, Roland Dreier |
|---|---|
| Next by Date: | Re: Advice needed on IP-over-InfiniBand driver, Roland Dreier |
| Previous by Thread: | Re: Advice needed on IP-over-InfiniBand driver, Roland Dreier |
| Next by Thread: | Re: Advice needed on IP-over-InfiniBand driver, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |