From owner-freebsd-current Mon Nov 25 14:11:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 872BA37B401; Mon, 25 Nov 2002 14:11:24 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC6D43E88; Mon, 25 Nov 2002 14:11:23 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id gAPMAaE75851; Mon, 25 Nov 2002 17:10:36 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Mon, 25 Nov 2002 17:10:36 -0500 From: Bosko Milekic To: Sam Leffler Cc: Robert Watson , Andrew Gallatin , Luigi Rizzo , current@FreeBSD.ORG Subject: Re: mbuf header bloat ? Message-ID: <20021125171036.B75673@unixdaemons.com> References: <235101c294b2$e66ce160$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <235101c294b2$e66ce160$52557f42@errno.com>; from sam@errno.com on Mon, Nov 25, 2002 at 10:46:00AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Nov 25, 2002 at 10:46:00AM -0800, Sam Leffler wrote: > > > I don't see this problem; looutput looks to do the right thing. FWIW > I've > > > passed mbufs w/ mtags through the loopback interface. > > > > This refers specifically to the following code snippet: > > > > if (m && m->m_next != NULL && m->m_pkthdr.len < MCLBYTES) { > > struct mbuf *n; > > > > MGETHDR(n, M_DONTWAIT, MT_HEADER); > > if (!n) > > goto contiguousfail; > > MCLGET(n, M_DONTWAIT); > > if (! (n->m_flags & M_EXT)) { > > m_freem(n); > > goto contiguousfail; > > } > > > > m_copydata(m, 0, m->m_pkthdr.len, mtod(n, caddr_t)); > > n->m_pkthdr = m->m_pkthdr; > > n->m_len = m->m_pkthdr.len; > > n->m_pkthdr.aux = m->m_pkthdr.aux; > > m->m_pkthdr.aux = (struct mbuf *)NULL; > > m_freem(m); > > m = n; > > } > > > > Something is wrong with your tree: > > ebb% grep aux ../sys/mbuf.h > ebb% > > The above code is correct in the repo as is the m_getcl code. While the 'aux' part of the code was in fact removed, what Robert is saying still applies. What happens is that this code 'manually' performs a mbuf to mbuf+cluster copy because of some pretty bogus assumption in the KAME code that expects the data to be contiguous in a single cluster. So when the 'n' mbuf is allocated and the cluster with it then a shallow copy of the packet header is done from mbuf 'm' (the old mbuf) to the newly allocated mbuf 'n'. What Robert is saying is that this copy breaks his MAC label semantics which require a deeper copy in this case and he is concerned that it may break the m_tag semantics too, especially given the fact that the old mbuf 'm' is then freed (doesn't this destroy the label?!). If that's indeed the case, then this copy remains bogus. > Sam -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message