Robert Watson wrote:
...
(3) Some consumers of ifnets need to be taught to register the ifnet
removal
event and properly detach themselves. For example, DUMMYNET is a
well-known component that likes to hold onto mbufs for a long time,
increasing the chances of the "oh, my ifnet is gone" race. Rather
than
trying to refcount from each mbuf, which would add excessive
overhead, I
think the answer is to modify these consumers to detect ifnet
removal and
GC all the mbufs that refer to it. For example, DUMMYNET should
probably
walk all its queues and m_freem() packets refering to the dying
ifnet.
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.
cheers
BMS
_______________________________________________
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"
