Date: Wed, 22 Apr 2009 10:41:19 +0100 From: Bruce Simpson <bms@incunabulum.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r191367 - head/sys/net Message-ID: <49EEE63F.2060706@incunabulum.net> In-Reply-To: <alpine.BSF.2.00.0904221028230.67705@fledge.watson.org> References: <200904212243.n3LMhW48027008@svn.freebsd.org> <49EEDB9C.8080409@incunabulum.net> <alpine.BSF.2.00.0904221028230.67705@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49EEE63F.2060706>