From owner-freebsd-stable@FreeBSD.ORG Thu Aug 7 06:25:54 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C96711065671 for ; Thu, 7 Aug 2008 06:25:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B78AB8FC1B for ; Thu, 7 Aug 2008 06:25:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id EE89F1A4D83; Wed, 6 Aug 2008 23:05:56 -0700 (PDT) Date: Wed, 6 Aug 2008 23:05:56 -0700 From: Alfred Perlstein To: David G Lawrence Message-ID: <20080807060556.GD16977@elvis.mu.org> References: <20080804020228.GG1663@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080804020228.GG1663@tnn.dglawrence.com> User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, Robert Watson Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2008 06:25:54 -0000 * David G Lawrence [080805 11:37] wrote: > > The thrust of this change is to replace the mutexes protecting the inpcb > > and inpcbinfo data structures with read-write locks (rwlocks). These > > That's really cool and directly affects my current work project. I'm > developing (have developed, actually) a multi-threaded, 5000+ member VoIP/SIP > conferencing server called Nconnect. It a primarily UDP application running > on FreeBSD 7. This generates and receives about 250,000 UDP packets a second, > with 200 byte packets, resulting in about 400Mbps of traffic in each > direction. The current bottleneck is the kernel UDP processing. It should > be possible to scale to 10000+ members if kernel UDP processing had optimal > concurrency. > Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm > looking forward to the MFC. David, one thing I noticed was that it appears that UDP sockets are serialized for copyout. Mainly that the socket is sblock()'d while the uiomove happens. I was trying to figure out a way to bypass this somehow. Perhaps just dequeuing and unlocking, the copyout after dropping the sblock. If there's some error, then requeue or discard the packet. I'll have to think about it. -Alfred