netdev - Re: many sockets, slow sendto

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 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]

Date:	Tue, 20 Mar 2007 23:48:38 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Zacco <zacco@...hu>
CC:	David Miller <davem@...emloft.net>, baruch@...en.org,
	netdev@...r.kernel.org
Subject: Re: many sockets, slow sendto

Zacco a écrit :
> Hi,
> 
> David Miller wrote:
>> From: Zacco <zacco@...hu>
>> Date: Tue, 20 Mar 2007 00:10:19 +0100
>>
>>  
>>> As you recommended, I used oprofile and it turned out that the 
>>> __udp4_lib_lookup function spent most of the time. There is a udp 
>>> hash table and the sockets are sought based on the 7 LSBs of the 
>>> destination port number. So what happened is now quite obvious: I had 
>>> many thousands of sockets, all with the same destination port, thus 
>>> linked in the same slot of this hash table. I tried using different 
>>> ports and it
>>> was much faster then.
>>>     
>>
>> There isn't much we can do here.  I bet your destination address
>> is unchanging just like your destination ports.
>>   
> As I'm simulating independent users on one host, each user has a 
> different IP address, but each with the same port. So unlike the port, 
> the address is changing, basically it's a huge A-class range.
> 
>> UDP apps can and do bind to specific destination addresses and
>> ports, but the source side is usually wild-carded.
>>   
> Right, usually it is, but in my case the source addresses are also 
> bound, otherwise the source address would be the primary address of the 
> physical interface; however, I need to simulate users as if they were on 
> separate hosts.
>> Are both the source address and port fully specified for your
>> sockets?  Maybe we can do something using if that's the case...
>>   
> You made me curious.  :)  What do you have in mind?

Currently, udp_hash[UDP_HTABLE_SIZE] is using a hash function based on dport 
number only.

In your case, as you use a single port value, all sockets are in a single slot 
of this hash table :
To find the good socket, __udp4_lib_lookup() has to search in a list with 
thousands of elements. Not that good, isnt it ? :(

As udp_hash is protected by a single rw_lock, I guess we could convert the 
hash table to a RB-tree, with a key being : (dport, daddr)

At lookup time, we could do :

1) A full lookup with (dport, daddr)
2) if not found, a lookup with wildcard : (dport, 0)

I dont know if this is OK, because I dont know if it is possible to have 
several UDP sockets with the same (dport, daddr)

It would be more scalable. But still the rw_lock is not very SMP friendly...


-
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