In message <1100010906.847533.1331.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:
[...]


>> > 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,
and exactly how does placing small mbufs physically adjacent to the
large external mbufs help you achieve this?


[...]

>> 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. 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.)


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.

Unless of course you're willing to burn 2* MCLBYTES worth of memory
per external cluster. Or to allocate the memory `leftover' after
subtracting one cluster-plus-adjacent header, and allocate that memory
usefully elsewhere.