Subject: Re: rfc: socketing it to gre
To: Bill Stouder-Studenmund <wrstuden@NetBSD.org>
From: Bill Stouder-Studenmund <email@example.com>
Date: 09/18/2007 12:23:07
Content-Type: text/plain; charset=us-ascii
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:
> > 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----