Date: Tue, 12 Nov 1996 09:29:21 -0800 From: Julian Elischer <julian@whistle.com> To: Mark Tinguely <tinguely@plains.nodak.edu> Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: -current mbuf reference function Message-ID: <3288B3F1.41C67EA6@whistle.com> References: <199611121610.KAA13353@plains.nodak.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Tinguely wrote: > > I don't think the external reference (m_ext.ext_ref) function in the -current > sys/mbuf.h is complete. First, the function m_copypacket in kern/uipc_mbuf.c > only uses the old style reference incrememnt of: > > mclrefcnt[mtocl(m->m_ext.ext_buf)]++ > > and even worse the MCLFREE macros in sys/mbuf.h only uses: > > --mclrefcnt[mtocl(p)] == 0 > > to decrement the reference count and check to see if it time to release. > > I think either a increment/decrement flag is needed to m_ext.ext_ref, or an > additional decrement function is needed, and this function is needed in the > MCLFREE macro. > > --mark. This code was originally in BSD4.3. We use it in our 4.3 , OSF1 and FreeBSD based systems to pass around externally defined objects the idea is that if the M_EXT flag is set but there is no ext_free function defined, then is is a default Mbuf cluster and the default functions are called. If there is a special ext_free function defined then use it instead. A cleaner method would be to Impliment the default functions in the same was as teh exception functions, in other words always have ext_free and ext_ref pointers defined, but in the default case they point to the default functions. I think it wasn't done that way simply to reduce the impact of the change, as the Mbuf cluster code was pre-existing. the function ext_ref is to increment the number of references to the object (e.g. if you were to duplicate the mbuf, but not duplicate the buffer,) and the ext_free routine is to decrement the references, (and presumably free the item in an item-specific manner if the reference count reaches 0 ). The MCLFREE macro is not included in the MFREE macro only because that would duplicate the MBUFLOCK code. The MCLFREE code should only be called if the ext_free entry is NULL (as it is set to NULL in MCLGET). It could be argued that the MCLFREE macro should be able to handle the case inn which the free function exists, and call that instead.. I don't know how many active cases of MCLFREE there are in the code.. I can probably put up a good case that there shouldn't be many if any. usually MFREE could surfice as usually the whole mbuf is being freed. there is a further enhancement from the OSF code that is rather stunningly brilliant, that Matt Thomas wants to bring in.. I once had a version that incoporated it as well.. (for some ATM code he wants to import I believe) I may still do it.. julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3288B3F1.41C67EA6>