Meem
Vanity naming support is not in SDP, we should be going away from bcmp() and check other attributes on the link as you have noted in your previous email. For sdp_pr_lookup(), the original plan was to use a proposed interface that Ashish was working on. But that did'nt happen. Later on after sdp integration, a large part of sdp_pr_lookup() functionality was pulled in into IB framework to make it available to RDS. As a result RDS is based on this newer functionality, but sdp did not cleaned up. But in general a large part of sdp_pr_lookup() should be replaced with the newer IB framework api. Peter Memishian wrote: > > 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. > Yes the functionality to check on the underlying interface is needed. So in addition to converting sdp_check_interface() support vanity naming, is there any additional IPMP specificness that sdp needs to be aware of ? > Thoughts? Also, who would be an appropriate code reviewer in this area, > and what testing would you recommend? > This function is executed in context of a connect() call in sdpland. So a simple sdp connect() success/failure(more importantly) should be sufficient to test this change. Nitin > Thanks a lot, >
