From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 01:42:11 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 9D509106567B; Sun, 10 Aug 2008 01:42:11 +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 83D458FC08; Sun, 10 Aug 2008 01:42:11 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7422F1A4D83; Sat, 9 Aug 2008 18:42:11 -0700 (PDT) Date: Sat, 9 Aug 2008 18:42:11 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20080810014211.GY16977@elvis.mu.org> References: <20080804020228.GG1663@tnn.dglawrence.com> <20080807060556.GD16977@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i 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: Sun, 10 Aug 2008 01:42:11 -0000 Robert, reviews of sorecv_drgram: /* XXXRW: sbwait() may not be as happy without sblock(). */ error = sbwait(&so->so_rcv); Does not need XXX, sbwait waits for data, it's not really related to sblock(). remove comment. The variable orig_resid can be removed, I think the purpose of it is to to restart blocking in the "generic sorecv" case, in your code you only set it, you never reference it. -Alfred * Robert Watson [080806 23:37] wrote: > > 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 -- - Alfred Perlstein