> FWIW it used to be that we wanted to send DL_DETACH_REQ to have the
> driver turn off interrupts etc. But with NWAM coming we'll always have
> the drivers active to be able to detect a cable that is plugged in, so
> this is just a historical note.
Moreover, IPMP has had the same requirement since we removed the need for
test addresses in S10, and I changed IP accordingly during S10
development via 4905976. (You've now provided the answer to the "unknown
historical reason" I cited in that bug report, though ;-)
> > So does that mean we can address this issue pre-ARP-merge?
>
> If you never detach and the drivers don't drop the multicast state on
> unbind (which would be a bug), then you should be able to fix this now.
> I assume the messages that go via ARP don't get reordered - if we do an
> ifconfig xx0 down up the DL_ENABMULTI from the up better be delivered to
> the driver after the DL_DISABMULTI_REQ from the down.
Looking at the code, ar_entry_squery() (which AFAIK is the only function
of note, since DL_{ENAB,DISAB}MULTI_REQ's are chained onto AR_ENTRY_SQUERY
messages sent to ARP) contains:
/*
* Newly received commands from clients go to the tail of the queue.
*/
if (CMD_NEEDS_QUEUEING(mp_orig, arl)) {
DTRACE_PROBE3(squery_enqueued, queue_t *, q, mblk_t *, mp_orig,
arl_t *, arl);
ar_cmd_enqueue(arl, mp_orig, q, AR_ENTRY_SQUERY, B_TRUE);
return (EINPROGRESS);
}
... and the definition of CMD_NEEDS_QUEUEING() seems robust. So I think
this is a safe bet. Since making ipif_multicast_up() symmetric would
simplify my IPMP work a bit, I plan to explore this further.
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
