--v9Ux+11Zm5mwPlX6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 14, 2007 at 04:09:08PM -0500, David Young wrote:
> On Fri, Sep 14, 2007 at 12:14:11PM -0700, Bill Stouder-Studenmund wrote:
> >=20
> > How much of a performance hit do we take for this?
>=20
> I haven't measured.  I will.

Thanks!

> I believe we will see an improvement in performance at the receiver when
> there are hundreds or thousands of tunnel interfaces, because the socket
> demux code uses a hash instead of walking a list.

Cool!

> I believe the socket code will be a better place to address performance
> problems than in code cut&pasted into umpteen different tunnel
> pseudo-interfaces.  Something I should have drawn more attention to in
> my original email was that hundreds of lines of code can disappear;
> I don't know if that will help somebody optimize NetBSD, but I don't
> think that their job is getting more complicated.  More on that, below.

As long as we don't have a punishingly-large performance hit, the cleaning=
=20
up in and of itself probably is a good enough reason to do this.

> > Would this permit us to do netgraph-like mix&match in the future?
>=20
> Maybe so.  What do you have in mind?

Nothing in particular. Just I remember hearing some about Netgraph being=20
able to create weird configuration topologies and it sounds like this=20
could also plumb stuff together.

> Let me tell you what I have in mind: I would like for there to be a tunnel
> "superclass."  Let us derive gif, gre, etherip from it by supplying a
> method that adds/subtracts the tunnel "shim" between the outer header
> and the inner packet.  As before, the user sees gif, gre, or etherip,
> but they are just personalities of the same code.  I think that stf
> and a hypothetical Teredo interface will withstand the same treatment,
> but they are a special case.

Cool!

Take care,

Bill

--v9Ux+11Zm5mwPlX6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFG8CWaWz+3JHUci9cRAqWrAKCJf44U0sf1+S9Dnllinc7HxnuVbACfey9T
ZxiKtuZh3Wl86C5Al3PSfH0=
=LzJR
-----END PGP SIGNATURE-----

--v9Ux+11Zm5mwPlX6--