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.
I did some work on this once.. things have got a lot more complicated however with locking..
P.S. I'm working on making protocols within protocols domains loadable at
least for IPv4.
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. :-)
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
