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

Date:	Wed, 21 Mar 2007 22:53:13 +0100
From:	Zacco <zacco@...hu>
To:	Eric Dumazet <dada1@...mosbay.com>
CC:	David Miller <davem@...emloft.net>, baruch@...en.org,
	netdev@...r.kernel.org
Subject: Re: many sockets, slow sendto

Eric Dumazet wrote:
>
> 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 ? :(
>
So, my worry is confirmed then. But how could that delay disappear when 
splitting the sender and receiver on distinct hosts? Even in that case 
the good socket must be found somehow.
> 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)
>
Actually, the source address would be more important in my case, as my 
clients (each with different IP address) wants to connect to the same 
server, i.e. to the same address and port.
I think, the current design is fair enough for server implementations 
and for regular clients. But even though my application is not tipical, 
as far as I know (but it can be important with the fast performance 
growth of regular PCs), the make-up should be general enough to cope 
with special circumstances, like mine. My initial idea was to somehow 
include the complete socket pair, i.e. source address:port and 
destination address:port, keeping in mind that it should work for both 
IPv4 and IPv6. Maybe it's an overkill, I don't know.
> 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)
Definitely, it is.
>
> It would be more scalable. But still the rw_lock is not very SMP 
> friendly...
>
Do you think there is interest in such a modification? If so, how could 
we go on with it?

thx: Zacco
-
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