Date: Tue, 23 Oct 2001 18:57:59 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Luigi Rizzo <rizzo@aciri.org> Cc: Alfred Perlstein <bright@mu.org>, net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023185759.A328@technokratis.com> In-Reply-To: <20011023140628.A36095@iguana.aciri.org>; from rizzo@aciri.org on Tue, Oct 23, 2001 at 02:06:28PM -0700 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011023185759.A328>