Subject: Re: rfc: socketing it to gre
To: Bill Stouder-Studenmund <>
From: Bill Stouder-Studenmund <>
List: tech-net
Date: 09/18/2007 12:23:07
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?
> I haven't measured.  I will.


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


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


Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)