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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
