hi,

> >> > Once we bite off designing a scalable MP-safe network buffer
> >> > allocation, the embedded m_ext is simply *not necessary* to acheive
> >> > either your goals or my goals.
> >> 
> >> how can you change mapping state of shared external storage,
> >> without the small shared header?
> 
> I repeat my own question: what `mapping state' do you need to change,

state of lazy mapping of loaned pages.  pages're initially unmapped
and then mapped into kernel address space when/if needed.
at that point, the storage might be shared by mbufs.

> and exactly how does placing small mbufs physically adjacent to the
> large external mbufs help you achieve this?

sorry, i don't understand what you're saying here.

> >> as i repeatedly said, freebsd5 uses the similar small headers.
> >> (which is embedded in slab headers for cluster mbufs,
> >> and malloc'ed in the case of m_extadd.)
> >> why do you ignore the point, or am i misunderstanding something?
> >
> >jonathan, can you please answer my this silly question?  thanks.
> 
> 
> As I beleive I said repeatedly: that is not what Milecik's BSDcon
> paper appears to say.  (To me, the paper seems to say there is a
> single `keg' which can allocate external storage or header mbufs; with
> enough space reserved in the zone headers to implement per-slab-object
> refcounts.

these refcounts are "small headers" i said above.

> Those refcounts are then used to implement
> per-external-storage refcounts. The FreeBSD `m_getcl() API atomically
> then allocates a header mbuf and a cluster; the per-CPu caches return
> suitable objects. But I could be misreading it.)

it seems that you're confusing between clusters (m_getcl) and
external storage (m_extadd).

> If, on the other hand, FreeBSD-5 is fragmenting the memory backing
> external mbuf storage, then that strikes me as a poor design
> choice. But it strikes me as a much, much worse choice for NetBSD, and
> the wider range of CPUs we run on.

then, do you have better alternative?

YAMAMOTO Takashi