On Fri, Sep 14, 2007 at 12:14:11PM -0700, Bill Stouder-Studenmund wrote:
> On Wed, Sep 12, 2007 at 11:08:17PM -0500, David Young wrote:
> > I have made a patch against -current that makes gre(4) exclusively use
> > sockets for packet (dis)encapsulation and (de)muxing.  In the new GRE
> > world order, you will not see gre(4) produce its own IP header, nor you
> > will find its hooks in the IP stack: sys/netinet/ip_gre.[ch] are no more!
> > The patch is at <ftp://cuw.ojctech.com/cuw/dyoung-9cb5d230/gre.patch>.
> > 
> > This is a work in progress.  Right now, the only encapsulations I
> > support are GRE in UDP in IPv4, and GRE in IPv4.  In the near future I
> > will support IPv6, and UDP in IPv6.  In principle, you could use some
> > OSI/AppleTalk datagram protocol for the encapsulation, but that's not
> > supported quite yet.
> 
> 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.

> Would this permit us to do netgraph-like mix&match in the future?

Maybe so.  What do you have in mind?

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.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24