In message <20030824222752.5902490@coconut.itojun.org>,
Jun-ichiro itojun Hagino  writes:

>	i guess you are ignoring cases with IPv4 mapped address, so you are
>	seeing simpler picture than me.
>	(NOTE: I'm not advocating it.  i'm very opposed of the idea of IPv4
>	mapped address.  however, for compatibility's sake we need to support
>	it no matter what)

Nope, I am definitely not ignoring it, I think its just not a common
case. I have a hacked-up tree (not ready for other eyes, yet) where
the fast-ipsec code compiles with a lightly-hacked NetBSD KAME netinet6/.

I count three placees where the fast-ipsec code currently needs to
care; and I could get that down to (probably) one, assuming the pcbs
had a unified prefix. (Note, I need to go back and dobule-check
against current KAME, to make sure the mapped-address case did not get
optimized away in the FreeBSD code I started with. There is a comment
saying the ``mapped-ipv6 address concern is implemented here'',
but it may not be, anymore.)

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.

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

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