> The issue is asynchrony in the IP/ARP/driver interaction. Due to ARP > being a separate module the DL_DISABMULTI_REQ which is embedded in the > AR_ENTRY_SQUERY is an asynchronous operation. The response comes back to > IP which then sends the DL_DISABMULTI req to the driver. > > Since we can't send that to the driver after the > DL_UNBIND_REQ/DL_DETACH_REQ, the code instead assumes that the > DL_UNBIND_REQ implicitly cleans up the multicast registrations in the > driver. > > Note that if we knew that we wouldn't bring down the whole ill i.e. that > we are not going to send a DL_UNBIND_REQ, then we could to the DISABMULTI.
I'm confused. According the DLPI specification, DL_DISABMULTI_REQ is valid in any state other than DL_UNATTACHED. DL_UNATTACHED only happens when a DL_DETACH_REQ is done (for DL_STYLE2 only). And as per 6522958, IP almost never sends a DL_DETACH_REQ today (and I'm about to rip out the code that does as part of fixing that bug). So does that mean we can address this issue pre-ARP-merge? -- meem _______________________________________________ networking-discuss mailing list [email protected]
