From owner-freebsd-net Tue Oct 23 15:59:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id CC8D837B405 for ; Tue, 23 Oct 2001 15:59:28 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9NMvxp00467; Tue, 23 Oct 2001 18:57:59 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 23 Oct 2001 18:57:59 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023185759.A328@technokratis.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023140628.A36095@iguana.aciri.org>; from rizzo@aciri.org on Tue, Oct 23, 2001 at 02:06:28PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As I have stated to Luigi in private and as I have stated more than half a year ago now when this issue was first brought up by dwmalone, I believe that the correct way to deal with this issue is to have M_LEADINGSPACE and M_TRAILINGSPACE simply return the number of bytes that make up the leading space or trailing space, respectively, regardless of whether the underlying cluster/mbuf/ext_buf is marked writable or not. There is nothing in the name "M_LEADINGSPACE" and "M_TRAILINGSPACE" that implies anything having to do with the writability of the underlying buffer and therefore, these two should not be concerned with writability. The reason that the relevant code to do so in the first place was commented out in the code when it was imported is the result of a crude hack which was probably brought in when support for other external buffers (besides for just clusters) was implemented because while this was done, at the time, the support for marking said buffers "writable" did not exist, and so to minimize checking in code using the M_LEADINGSPACE and M_TRAILINGSPACE macros, they were merely made to return 0 in the event of an M_EXT marked mbuf. Instead, the correct approach would be, as stated above, to have M_LEADINGSPACE and M_TRAILINGSPACE return what their names imply and have the code that uses them in the kernel appropriately check for writability of the ext_buf before it's about to write to it, using the _already existing_ interface, i.e. M_WRITABLE(). Since this interface _exists_ and we have it implemented, there is no reason not to use it properly anymore. Yes, I'm willing to go around and do the work in -CURRENT, and I will do this, hopefully, by this weekend, as the [massive amount of] school work "stabilizes." I think the same approach should be taken in -STABLE. That said, I am not 100% opposed to Luigi's patch and I think that had not brought this up, it would have been left long forgotten. On Tue, Oct 23, 2001 at 02:06:28PM -0700, Luigi Rizzo wrote: > On Tue, Oct 23, 2001 at 02:00:34PM -0500, Alfred Perlstein wrote: > > > > Yes, you're right, I was mistaken in my paranioa, however you're > > missing the fact that one may want to allocate an EXT buf and still > > have it writeable. > > Yes, but this is the sort of things that are better sorted out > in -current... > > > I like your patch, it's a good idea, go for it. > > good to hear that :) > > cheers > luigi Cheers, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message