Date: Fri, 26 Oct 2001 13:28:37 -0700 From: Bill Fenner <fenner@research.att.com> To: bmilekic@technokratis.com Cc: rizzo@aciri.org, keiichi@iij.ad.jp, dwmalone@maths.tcd.ie, bright@mu.org, net@freebsd.org Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <200110262028.NAA12437@windsor.research.att.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> <20011026092840.F64631@iguana.aciri.org> <20011026133827.A22096@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> The M_LEADINGSPACE macro always had the line of code that would return >the leading space even for ext_bufs commented out, suggesting that the >code did exist in the original implementation or was intended to. The M_LEADINGSPACE macro was introduced in rev 7.11 of mbuf.h, in August 1988, at the same time as the "new" mbufs, i.e. when external sotrage was introduced, m_act renamed to m_nextpkt, etc. Perhaps the commented code is there to remind what the right thing to do is once you can tell whether or not external storage is writable. I don't think it's reasonable to say that the presence of the comment makes it completely obvious what the intentions of this code were in 1988. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110262028.NAA12437>