HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you

[Robert Watson]

On Wed, 6 Aug 2008, Alfred Perlstein wrote:

> * David G Lawrence <dg at 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