Subject: Re: mbuf external storage sharing
To: None <>
From: YAMAMOTO Takashi <>
List: tech-net
Date: 10/09/2004 06:33:01

> My point, however, is that when I look at the actual uses of your
> fused ``atomically get an tiny-mbuf and external mbuf'', those uses
> were in NIC drivers. Specifically, for acquiring new DMA buffers for
> receive-side DMA queues.
> In *that* case, if we allocate from per-CPU pools in the common case,
> you don't need spinlocks or atomic increments *at all*, for the
> initial allocation. And there are good, and very well-known reasons,
> why having per-CPU pools is a Good Thing.

as i already said, i'm not against it.
i think that it's a good idea but i don't need it at this point because
it's orthogonal to my patch.

> >	(it might be good to have MI-exposed atomic_ operations like
> >	freebsd and linux.  but it's a separate topic.)
> >
> >- how to allocate/free mbufs and clusters
> >	freebsd5 has some optimizations, including m_getcl.
> >	although they might be good and i have no objections against them,
> >	they're orthogonal to my patch.
> You keep saying the issues are orthogonal.  To me, it seems quite
> plain that they are not orthogonal. If we do per-CPU pools, then we
> can do efficient SMP-safe allocation *without* fusing a tiny-mbuf
> header into a smaller variant of a cluster mbuf. (If your goal is
> space efficiency, there is prior art for better approaches.)

per-CPU allocation pools don't affect how MCLADDREFERENCE works at all.
they're clearly orthogonal.

sorry, honestly speaking, i doubt if you have actually read my patch or
freebsd5 code.
if you read freebsd5's bge driver, you will find that bge_newbuf_jumbo
attaches an external buffer using MEXTADD (== m_extadd).
m_extadd then allocates a small header using malloc.
i don't see why you think that it contradicts to my patch.
to me, it seems quite similar to what my patch does.

> We are clearly talking at cross-purposes, but I still don't see where
> or why.  Perhaps you could explain once more what the intended purpose
> of your patch is?

my purposes are:
- being more mp-safe.
- preparing to implement lazy mapping of loaned pages, which can need to
  change a state (mapped/unmapped) of shared mbuf.