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