netdev - Re: [RFC] [PATCH] udp: optimize lookup of UDP sockets to by including destination address in the hash key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200911051903.02859.opurdila@ixiacom.com>
Date:	Thu, 5 Nov 2009 19:03:02 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Lucian Adrian Grijincu <lgrijincu@...acom.com>,
	netdev@...r.kernel.org
Subject: Re: [RFC] [PATCH] udp: optimize lookup of UDP sockets to by including destination address in the hash key

On Thursday 05 November 2009 18:36:50 you wrote:
> Octavian Purdila a écrit :
> > IIRC, we first saw this issue in VoIP tests with up to 16000 sockets
> > bound on a certain port and IP addresses (each IP address is assigned to
> > a particular interface). We need this setup in order to emulate lots of
> > VoIP users each with a different IP address and possible a different L2
> > encapsulation.
> 
> Interesting case indeed, is it SIP 5060 port or RTP ports ?
> (I want to know how many messages per second you want to receive)
> 
> An rbtree with 16000 elements has 15 levels, its a lot, but OK
> for small trafic.
> 

Yep the signaling port not the RTP port, and yes I think there is a fairly  
small amount of traffic and rbtree might work.

BTW, there is another side of this problem, the time to bind() those 16K 
sockets before starting the test - at least on 2.6.7 we didn't yet get to look 
at this issue on a recent kernel.

Thanks,
tavi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html