> 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.
Understood. But I'd rather not do that rewrite as part of Clearview,
since it's out-of-scope.
Could you review my proposed changes to sdp_link.c and ibcm_arp_link.c?
/net/zhadum.east/export/ws/clearview/clearview-ipmp/webrev
> 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 ?
AFAIK, just the source-IP-address -> source MAC address mapping issue I
mentioned before. Please see my webrev. For purposes of review, you can
assume that ipmp_ipif_hold_bound_ill() will return the ill_t that will
be used to receive packets for the specified source address, and can also
be used to transmit packets for the IPMP group. Note that ARP's ACE
entries are associated with the IPMP group interface (rather than an
underlying interface), so providing the IPMP group interface's ill_name
when contacting ARP is appropriate.
> > 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.
I presume I need a machine with appropriate hardware? Also, are there
already test cases that do this in a test suite somewhere?
Thanks,
--
meem
