Date: Tue, 18 Jul 2000 18:45:11 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Bosko Milekic <bmilekic@dsuper.net> Cc: David Malone <dwmalone@maths.tcd.ie>, net@freebsd.org, iedowse@maths.tcd.ie, sheldonh@freebsd.org, jlemon@freebsd.org, wollman@freebsd.org Subject: Re: kern/19866: The mbuf subsystem refcount stuff. Message-ID: <20000718184511.O13979@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.21.0007182059540.37767-100000@jehovah.technokratis.com>; from bmilekic@dsuper.net on Tue, Jul 18, 2000 at 09:09:36PM -0400 References: <20000718160033.H13979@fw.wintelcom.net> <Pine.BSF.4.21.0007182059540.37767-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
moved over to -net.
* Bosko Milekic <bmilekic@dsuper.net> [000718 18:08] wrote:
>
> On Tue, 18 Jul 2000, Alfred Perlstein wrote:
>
> > That never happens. If you have an mbuf it's _yours_ no one will
> > deref it out from under you otherwise it wouldn't work at all. You
> > can NOT pass an mbuf you some subsystem and then free it, you must
> > pass a _copy_ of it if you want to use it again later (attach
> > another mbuf header and increase the ref count), therefor the
> > refcount will be 1 higher and even if it's free()'d at intr you'll
> > never go to 0.
>
> Alfred, it's not the MBUF that is being referenced, it's the ext_buf
> attached to the m_ext of the mbuf, which CAN be referenced by multiple
> mbufs. The idea is to have the referencing handled by the mbuf because a
> single mbuf can only map ONE external object.
Er, that's what I meant. The refcount is never 0 unless it's completely
free.
> > The reason is to hopefully avoid locking the entire pool or locking
> > 3 objects to make a single cluster copy. I'm not saying that you
> > have to make 3 locks, but I can't see it any other way:
> > myself, backward, forward -> manip pointers
>
> By that logic you're going to have to make per CPU pools and add many
> more hysterics to the system. This is not even the beginning of your
> problems if your plan is to re-invent the wheel. But if you do plan to do
> that, count on me to help you if you request it in the future, however,
> don't avoid new things from going in because of it. :-)
>
> > Actually, I would like to see it go in, the macro approach will
> > make it easy to move it over the pointer to refcount memory idea,
> > I'd just hoped that you would have done it my way. Your work
> > will take us halfway there and be very benificial in the meanwhile
> > by reducing the amount of callbacks needed when sending clusters
> > as well as simplifying a lot of code and special cases.
>
> If you have an alternate suggestion that is different than the
> existing one (i.e. get absolutely rid of that mclrefcnt global array),
> that will WORK, and that is better than what I just proposed (which is
> actually taken from NetBSD in part), then I'm all ears and ready to
> implement! (By know, you know that I have no problem writing code for
> the project)
Ok here's an idea that I was tossing around:
you have a freelist of these guys, one for each mbuf header,
you can make less and deal with failure by sleeping or failing
as you want, but for the sake of example one is available for
each mbuf at any given time.
struct mclrefcnt {
struct mclrefcnt *mextr_next; /* XXX: use list macros :) */
atomic_t mextr_refcnt;
};
and a pointer to one in each mbuf.
when you want to make a copy your code looks something like this:
/* copying m into n */
if (m->rp == NULL && n->rp == NULL) {
m->rp = n->rp = mclrefcnt_alloc();
} else if (m->rp == NULL) {
m->rp = n->rp;
} else if (n->rp == NULL) {
n->rp = m->rp;
} else {
mclrefcnt_free(n->rp);
n->rp = m->rp;
}
atomic_inc(m->rp.mextr_refcnt);
/* freeing m */
/* x must get the value I reduced it to */
x = atomic_dec_and_fetch(m->rp.mextr_refcnt);
if (x == 0) {
/* do extfree callback */
} else {
m->rp = NULL;
}
/* free mbuf header */
Are there problems you see with that?
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
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?20000718184511.O13979>