> APIs already exists in the IB framework (see PSARC/2007/323) that > several IB ULPs, such as RDS (Reliable Datagram Sockets), use to perform > the lookup function. SDP is not using those IB framework APIs. The IB > framework APIs invoke the code in ibcm_arp_pr_lookup().
Got it, thanks for explanation. I'm still a little bit confused about how ibt_get_paths(9F) interacts with IP/ARP (does it?), but other than that, things make sense now. > No new IB APIs are being requested. However, is this a good time to > suggest/request that someone implement the changes described in RFE > 6399103 which includes APIs described in PSARC/2006/482? When those > changes are made, the IB folks would update the IB framework to use them. I see that as a mostly-orthogonal matter, in that most of the complexity there is associated with asking ARP to retrieve the hardware address for a destination IP, whereas the issues I'm running into are due to the existing logic (which doesn't involve ARP at all) to map the source (system-local) IP address to its hardware address. While we could use a generic IP-address -> hardware address mapping function to accomplish both, it seems a bit of a fringe benefit, and as such I'm concerned about scope creep for the IPMP work. Further, assuming the interface "check" logic will still be needed, we'll still need *_pr_lookup() to understand IPMP enough to do the check on an underlying interface instead of an IPMP interface, which means most of my proposed code changes would still apply. Thoughts? Also, who would be an appropriate code reviewer in this area, and what testing would you recommend? Thanks a lot, -- meem
