From owner-freebsd-current Thu Nov 28 9:34: 2 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 ADD8537B401; Thu, 28 Nov 2002 09:34:00 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D56C643EC2; Thu, 28 Nov 2002 09:33:59 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gASHXu9i035676 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 28 Nov 2002 09:33:57 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <086401c29704$54c05770$52557f42@errno.com> From: "Sam Leffler" To: "Bosko Milekic" Cc: "Robert Watson" , "Andrew Gallatin" , "Luigi Rizzo" , References: <235101c294b2$e66ce160$52557f42@errno.com> <20021125171036.B75673@unixdaemons.com> Subject: Re: mbuf header bloat ? Date: Thu, 28 Nov 2002 09:33:56 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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. > The real code (i.e. what was checked in when I replaced the aux mbufs w/ tags) doesn't do the above; it does the right thing; albeit using the binary copy of the mbuf instead of using the appropriate macro. Regardless Robert and I have been working through the details of revising the system handling of pkthdr's. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message