Date: Thu, 14 Oct 2004 15:50:50 -0700 From: Julian Elischer <julian@elischer.org> To: Andre Oppermann <andre@freebsd.org> Cc: net@freebsd.org Subject: Re: small tun(4) improvement Message-ID: <416F02CA.5020700@elischer.org> In-Reply-To: <416EE620.186AD27A@freebsd.org> References: <20041014174225.GB49508@cell.sick.ru> <416EBF0A.CB1C0366@networx.ch> <20041014202305.GA50360@cell.sick.ru> <416EE620.186AD27A@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andre Oppermann wrote: >Gleb Smirnoff wrote: > > >>On Thu, Oct 14, 2004 at 08:01:46PM +0200, Andre Oppermann wrote: >>A> > any objections about commiting this improvement to tun(4)? >>A> > In my ng_device I have a similar function ngdwrite(), which was >>A> > cut-n-pasted from tunwrite(). And my tests with a patched ng_device have >>A> > shown 30% speedup on large writes. I don't think it will help tun(4) >>A> > to be a much faster, since tunwrite() isn't a bottleneck, but I think >>A> > it is worth considering. The patch was tested on a production PPPoE access >>A> > concentrator (RELENG_4 however). >>A> >>A> Could you check tap(4) as well? You can do the same optimization there >>A> as well (IIRC). >> >>Yes, you are right. >> >>We are going to have triple cut'n'paste: if_tun.c, ng_device.c, if_tap.c. >>What about m_uiocopy()? The question is where can we put this function? >> >> > >What about the existing m_uiotombuf() function in kern/uipc_mbuf.c? > > > >>P.S. We already have md_get_uio() in libmchain. But it doesn't do exactly >>same thing. And libmchain does not support Big Endians, so we probably >>don't want to make tun and tap depend on libmchain. >> >> > >Already answered ;-) > > > >>P.P.S. BTW, ng_eiface+ng_device is going to supersede tap(4), same way as >>ng_iface+ng_device is going to supersede tun(4). :) >> >> >Yes and no. While the netgraph equivalents may have the same functionality >we want to keep the existing and well-known API's to keep porting easier. >On top of that there is nothing wrong with tap(4) and tun(4) (except the >mbuf inefficiency you are about to fix). > my thoughts exactly.. THOUGH there might be some synergy where we save or share code.. If netgraph becomed useful enough then it'll start to to be used for this sort of thing.. but I'm not for removing existing interfaces. > >P.S. I'm working on making protocols within protocols domains loadable at >least for IPv4. > I did some work on this once.. things have got a lot more complicated however with locking.. >I'm using this to make DIVERT a loadable module. > cool.. the trick is to work out how to make it (un)attach to ipfw.. > However >there's nothing preventing a netgraph module (ng_ipproto perhaps?) using the >same hooks. I think this would make netgraph quite some more usable as it >already is. Then you can implement new IP protocol types including sockets >towards userland in netgraph. My code should be ready by next week. :-) > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416F02CA.5020700>