On Mon, 25 Aug 2003, Jun-ichiro itojun Hagino wrote:

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

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.

> 	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

No, that's wrong. As you state below, it's not the _only_ way to tell,
it's just the way you chose.

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

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.

Take care,

Bill