Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Aug 2008 07:37:55 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        stable@FreeBSD.org
Subject:   Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
Message-ID:  <alpine.BSF.1.10.0808070737090.89358@fledge.watson.org>
In-Reply-To: <20080807060556.GD16977@elvis.mu.org>
References:  <alpine.BSF.1.10.0808031142550.65130@fledge.watson.org> <20080804020228.GG1663@tnn.dglawrence.com> <20080807060556.GD16977@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0808070737090.89358>