> Individual cases like this may not seem important, but when your
> machine is handling 200,000 packets per second, they all add up.
> Delivering good performance (largely through attention to such
> details), is one of the reasons fast-ipsec is, well, fast,
> and why we (NetBSD) reached a consensus to go with fast-ipsec.

	sorry, which part of the cost is the concern?  why it is so bad to
	pass socket * to fast-ipsec routine, and fast-ipsec routine to extract
	inpcb * (or inpcbpolicy *) and use it internally?

> >	the only way you can tell which L3 protocol being used is to see
> >	so->so_proto->pr_domain->dom_family.  so i don't see the point in
> >	passing inpcb * when you need to go back to socket * anyways.
> 
> ... because I see it as ugly and unnecessary, and it could be done
> away with altogether if ipv4 mapped addresses were to magically
> disappear .

	unfortunately IPv4 mapped address won't disappear.

> (Or, ugh, we add a flag to the hypothetical in[6]pcb prefix: ugh, yuck.
> But to me, less yucky than pushing the struct socket* into places that
> have _no business_ seeing, or examining, socket-level internals.)

	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.

itojun