On Wed, 22 Apr 2009, Bruce Simpson wrote:
I'm not familiar with the workings of SSM, but my feeling is that it
probably needs to take the (3) approach rather than (2) -- rather than
preventing the ifnet from going away until a socket closes, it should
detect that the ifnet is going away and take appropriate remedial action.
Possibly it should detect when a similarly configured ifnet re-appears and
consider attaching to that, but it will most likely be a different instance
of struct ifnet, and there are semantic considerations.
SSM isn't high traffic -- it actually reduces the chattiness of IGMP by
implementing per-interface output queues and state change report merges.
Same for MLDv2 in IPv6. Timeliness and stability are what counts, it's
control plane, not data plane. At the moment it mostly does (3) by doing an
ifindex lookup in the netisr dispatch callback before calling ip_output().
Of course if ip_output() were to look before it leapt, the book keeping
involved would go away. I have to stash the vimage context and ifindex in
the queued mbuf packet headers to implement this.
Now that Giant is nuked, the netisr could be eliminated and the ifnet rlock
taken as it is before dispatching an entire chain. I only implemented a
netisr to allow the code to be back-ported, however I don't care about
back-porting any more -- it's too much effort and the time/funding budget
doesn't justify that amount of work.
Have you thought about registering a callback with the ifnet_departure_event
event handler to handle interfaces disappearing?
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
