Date: Sun, 6 Oct 2002 23:32:34 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Sam Leffler <sam@errno.com> Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch Message-ID: <Pine.BSF.4.21.0210062329200.22932-100000@InterJet.elischer.org> In-Reply-To: <13e901c26dbb$63059f60$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is not a techincal comment but more a project question.. What is the relationship between these changes and the KAME code? In particular, are they goign to take these changes back into Kame? Can you outline the compatibility issues, both with KAME, and with NetBSD and OpenBSD, as I know you have been looking at OpenBSD? (Am looking at the patches now will respond technically searatly.) On Sun, 6 Oct 2002, Sam Leffler wrote: > http://www.freebsd.org/~sam/mtag.patch > > has changes to -current to replace the "aux mbuf" with a more general > mechanism borrowed from openbsd. Rather than dangling mbuf's off a packet > when auxiliary information needs to be associated with a packet a list of > variable-size struct m_tag's are kept. This is better because it: > > 1. Eliminates the use of mbufs as a general-purpose memory allocator. > 2. Avoids confusing and problematic code (e.g. ipsec stuffs multiple data > structures into an mbuf and often consults m_len to determine what > might/should be present). > 3. Means arbitrary size data can be stored (w/ mbufs you get what fits in a > fixed-size mbuf or--if it were implemented--in a cluster). > 4. Removes a recursive dependency that complicates locking in the mbuf code. > > The patch actually contains three sets of changes that are intertwined: > > 1. Remove use of aux mbufs and replace with m_tag's. > 2. Add an additional parameter to ip_output and ip6_output that was > previously passed through an aux mbuf. > 3. Rename luigi's m_tag_id hack #define to avoid name conflict with the > m_tag definition. > > I've been running something like this patch for ~9 months. The patch > actually eliminates more code than it adds and is likely to improve > performance (haven't measured). There should be no functional changes after > this patch is applied. > > Timely feedback is desired as I'd like to commit these changes in time for > DP2. > > Sam > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210062329200.22932-100000>