sorry for not getting back sooner.. > > I looked at the arp/ip related files above. the changes look mostly > > good but I have a few questions: > > > > ipif_arp_down has been renamed to ipif_resolver_down (which is fine) > > but the ILLF_XRESOLV related code in ipif_down_tail has been > > removed- why? (If we are going to remove ILLF_XRESOLV support, shouldn't > > we remove it uniformly)? > > > I don't think I changed this part of code?
Ok. I was diffing against onnv, and maybe there was a merge missing. > > is it possible that the arp gets the AR_INTERFACE_DOWN from the > > ip first, before it gets the DL_NOTE_REPLUMB, and the messages > > get interleaved so that the REPLUMB_DONE does not get sent (e.g., > > arp has sent the UNBIND to the driver, state is ARL_S_PENDING, > > and now the DL_NOTE_REPLUMB comes up to arp. Will arp_replumb_done > > be called? Would it be simpler to have ar_ll_down send the replumb_done > > after doing the detach (if needed)? > > > If arp gets the AR_INTERFACE_DOWN first, then ar_cmd_done() will send the > REPLUMB_DONE. Ok. > > (The clearview-fastpath-hg listed at the top of the webrev is > > slightly different from the clearview-fastpath-review files in this > > area, so I will refer to clearview-fastpath-review here) - if > > ar_dlpi_done encounters one/more DL_NOTIFY_CONF mp(s) at the end of the > > arl_dlpi_deferred chain, it will call ar_dlpi_dispatch to handle > > it but in this case, but after processing these, we would not > > reset arl_dlpi_pending or call ar_cmd_done(). Is that correct? > > > Meem pointed out there is some issues (missing ar_cmd_done()) and I will > send out the updated webrev soon. Ok, I'll wait to see the updated webrev, then. thanks! Sowmini
