From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 06:04:39 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 3B2FD16A4CE for ; Fri, 24 Sep 2004 06:04:39 +0000 (GMT) Received: from smtp05.web.de (smtp05.web.de [217.72.192.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1DD643D58 for ; Fri, 24 Sep 2004 06:04:38 +0000 (GMT) (envelope-from Waldemar.Kornewald@web.de) Received: from [80.134.69.149] (helo=[80.134.69.149]) by smtp05.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1CAjC2-0005lr-00; Fri, 24 Sep 2004 08:04:30 +0200 Message-ID: <4153B897.9040807@web.de> Date: Fri, 24 Sep 2004 08:03:03 +0200 From: Waldemar Kornewald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <4152A3E9.8080700@web.de> <20040923181605.GC25699@odin.ac.hmc.edu> <415339A1.6090905@web.de> <20040923211703.GA23574@odin.ac.hmc.edu> In-Reply-To: <20040923211703.GA23574@odin.ac.hmc.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Waldemar.Kornewald@web.de X-Sender: Waldemar.Kornewald@web.de cc: FreeBSD-net Subject: Re: locking & iovecs 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: Fri, 24 Sep 2004 06:04:39 -0000 Brooks Davis wrote: >>Oh, now that we talk about alternatives: did you consider using iovecs >>instead of mbufs? Be Inc. said that BONE, the new netstack of BeOS (now >>Zeta), can handle huge amounts of data much better than mbufs because >>iovecs reduce the number of copies made when fragmenting...though, there >>has never been a real comparison. > > Rewriting the network stack to use an alternate method of storing > network data is a hugh undertaking. It's not an idea that's likely to > get any sort of traction in the project unless someone presented running > code and a massive performance improvement across the entire spectrum of > applications. Unless you mean splitting buffers up into TCP packets, > fragmentations is a network configuration bug in 99% of all cases. :) Sorry, that is no bug. :) Maybe we will try it after we get our code/port stable. As we will not port all of your protocols it should be less of a problem to change our stack. I can post the results here (in some years ;). >>>You can implement mutexes using semaphores, but semaphores tend to be a >>>more expensive since they are more expressive them mutexes. >> >>Using a benaphore instead would improve speed significantly and as you >>only use macros we can easily replace those with our benaphore code, is >>that really so simple? Sorry, I cannot believe that. :) > > Once GIANT is really gone, it may be nearly that easy. We're a ways > from that though. So, the code is not fully thread-safe yet (we want to drop GIANT)? Then, I misunderstood something. Will 5.3 be freed of GIANT? Bye, Waldemar Kornewald