From owner-freebsd-stable@FreeBSD.ORG Thu Aug 7 06:37:58 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 6B82F106566B; Thu, 7 Aug 2008 06:37:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CAFBB8FC0C; Thu, 7 Aug 2008 06:37:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5008B46BC2; Thu, 7 Aug 2008 02:37:55 -0400 (EDT) Date: Thu, 7 Aug 2008 07:37:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20080807060556.GD16977@elvis.mu.org> Message-ID: References: <20080804020228.GG1663@tnn.dglawrence.com> <20080807060556.GD16977@elvis.mu.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org 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:37:58 -0000 On Wed, 6 Aug 2008, Alfred Perlstein wrote: > * 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. Or you can use the soreceive_dgram implementation in 8.x, which I will at some point MFC once I'm comfortable it doesn't contain any serious bugs. Robert N M Watson Computer Laboratory University of Cambridge