Peter Memishian wrote: >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? > > Correct.
>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. > That is correct. >In addition, I believe ipif_down_delete_ire() must also >condemn all IREs with an ire_stq->q_ptr matching ipif->ipif_ill, since > > Not exactly. We check based on the ipif_src_addr, and on the ipif itself, but not on the ire_stq. i.e. the ire should be related to the ipif. >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. > > There are other places where we delete IREs based on other matching conditions. In the case of IPMP, as you mentioned bringing down the last ipif on an ill, will remove the ill from the group. This action causes ill_handoff_responsibility -> illgrp_cache_delete to delete the 'ill' based ire matches. Other places where these 'ill' based matches happen are ill_downi, ill_stq_cache_delete, ill_ipif_cache_delete. In some sequences there could be redundant cleanups, but there shouldn't be any missed cleanup. Thirumalai >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. > > >
