> > 	sorry, which part of the cost is the concern?  why it is so bad to
> 
> so->so_proto->pr_domain->dom_family
> 
> That's a lot of cache churn. On IA32, we can kinda get by. But on other,
> less-beefy architectures, that really hurts.
> 
> The thing to remember is that with caches, the first de-reference of a
> pointer is expensive. The cost I've heard is around 1000 clock cycles.
> That will vary with architecture, but suffice it to say it'll be
> expensive.
> 
> And if dom_family is all that we're getting out of pr_domain, then we're
> poisoning the cache for little value.

	the pointer dereference is really a concern, you can keep so-to-family
	mapping table cache.

> > 	using a flag to distinguish between in{,6}pcb and sharing the structure
> > 	means that you need to update every kmem grovellers which looks at
> > 	inpcb structure.  it's not only netstat, but also all other thirdparty
> > 	packages including trafshow and such.  this is the major (i guess the
> > 	most important) reason why i did not touch inpcb structure when we
> > 	integrated KAME into netbsd.
> Well, adding a common pcb header will probably break things anyway. I'd
> say do the common PCB trick, and shove in a flag. It's much cleaner.

	where did the "principle of least surprise" go?  we should be more
	careful when proposing a change that would affect every thirdparty
	software (well, those who grovels inpcb).

itojun