From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 20:48:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E662816A4D1 for ; Thu, 14 Oct 2004 20:48:32 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D7E743D49 for ; Thu, 14 Oct 2004 20:48:32 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 20807 invoked from network); 14 Oct 2004 20:48:22 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Oct 2004 20:48:22 -0000 Message-ID: <416EE620.186AD27A@freebsd.org> Date: Thu, 14 Oct 2004 22:48:32 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041014174225.GB49508@cell.sick.ru> <416EBF0A.CB1C0366@networx.ch> <20041014202305.GA50360@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: small tun(4) improvement X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 20:48:33 -0000 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). 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. 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. :-) -- Andre