Thiru,
I was hoping you could shed some light on ipif_down_delete_ire().
Specifically, I ran into a problem with the current logic in my IPMP bits,
but I don't see why the same basic issue isn't a problem with Nevada.
Suppose ce0 and ce1 are placed into an IPMP group with two addresses[1]
and then creates some connections over those interfaces. That should
result in some IRE_CACHE entries being created for those connections; each
IRE_CACHE entry will have an ire_ipif pointing at one of the address ipifs
and an ire_stq (effectively) pointing at one of the output ills, right?
Now, suppose "ifconfig ce0 down" is done to bring down the (only) IFF_UP
address on ce0. As part of bringing the interface down, ipif_down() calls
ipif_down_delete_ire() to condemn all of the IREs associated with the
ipif's address. In addition, I believe ipif_down_delete_ire() must also
condemn all IREs with an ire_stq->q_ptr matching ipif->ipif_ill, since
ipif_is_quiescent() will wait for ipif->ipif_ill->ill_ire_cnt to reach
zero (for the last up ipif on an ill), and that will only happen when all
of the IREs making use of it have become unreferenced. However, if the
IREs with ire_stq->q_ptr == ipif->ipif_ill are not condemned, ipif_down()
-> conn_cleanup_stale_ire() will not trigger the conn_t's using those IREs
to release their references and the "down" will hang.
Am I overlooking something here? How does the current logic in
ipif_down_delete_ire() not cause problems with IPMP in Nevada? Is there a
reason it doesn't check ire_stq->q_ptr == ipif->ipif_ill?
Thanks for any clues.
[1] I'm being intentionally vague about what ill/ipif hosts those
addresses, as I think the issue arises both in the old and new
IPMP code.
--
meem
