Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Oct 2002 22:02:01 -0700 (PDT)
From:      Nate Lawson <nate@root.org>
To:        freebsd-arch@freebsd.org
Cc:        freebsd-net@freebsd.org
Subject:   Re: CFR: m_tag patch
Message-ID:  <Pine.BSF.4.21.0210062200110.5730-100000@root.org>
In-Reply-To: <13e901c26dbb$63059f60$52557f42@errno.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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

I'm not familiar with that code so only a few questions:

1. Is ordering important or is an SLIST sufficient for all cases?
2. Is it possible to attach the aux argument to the mbuf chain instead of
adding it as a new parameter to ip_output?

-Nate


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.0210062200110.5730-100000>