Date: Sat, 9 Aug 2008 18:42:11 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you Message-ID: <20080810014211.GY16977@elvis.mu.org> In-Reply-To: <alpine.BSF.1.10.0808070737090.89358@fledge.watson.org> References: <alpine.BSF.1.10.0808031142550.65130@fledge.watson.org> <20080804020228.GG1663@tnn.dglawrence.com> <20080807060556.GD16977@elvis.mu.org> <alpine.BSF.1.10.0808070737090.89358@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rwatson@FreeBSD.org> [080806 23:37] wrote: > > On Wed, 6 Aug 2008, Alfred Perlstein wrote: > > >* David G Lawrence <dg@dglawrence.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080810014211.GY16977>