On Tue, 2006-07-11 at 18:17 +1000, Herbert Xu wrote: > On Fri, Jul 07, 2006 at 01:25:44PM -0500, Steve Wise wrote: > > > > Some IP networking is involved for this. IP addresses and port numbers > > are used by the RDMA Connection Manager. The motivation for this was > > two-fold, I think: > > > > 1) to simplify the connection setup model. The IB CM model was very > > complex. > > > > 2) to allow ULPs to be transport independent. Thus a single code base > > for NFSoRDMA, for example, can run over Infiniband and RDMA/TCP > > transports without code changes or knowing about transport-specific > > addressing. > > > > The routing table is also consulted to determine which rdma device > > should be used for connection setup. Each rdma device also installs a > > netdev device for native stack traffic. The RDMA CM maintains an > > association between the netdev device and the rdma device. > > > > And the Infiniband subsystem uses ARP over IPoIB to map IP addresses to > > GID/QPN info. This is done by calling arp_send() directly, and snooping > > all ARP packets to "discover" when the arp entry is completed. > > This sounds interesting. > > Since this is going to be IB-neutral, what about moving high-level logic > like this is moved out of drivers/infiniband and into net? > > That way the rest of the networking community can add input into how > things are done. >
The notifier patch I posted sort of does this already by eliminating the need to snoop arp replies. It will notify interested subsystems of neighbour changes (EG when an ARP reply is processed and the neighbour struct updated with the correct hw mac addr). And I _think_ neigh_event_send() could be used instead of arp_send(). Steve. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
