From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 21 Mar 2007 23:12:40 +0100
[PATCH] INET : IPV4 UDP lookups converted to a 2 pass algo
Some people want to have many UDP sockets, binded to a single port but many
different addresses. We currently hash all those sockets into a single chain.
In article [EMAIL PROTECTED] (at Mon, 30 Apr 2007 00:26:43 -0700 (PDT)),
David Miller [EMAIL PROTECTED] says:
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
Eric, I've applied this, thanks again.
Could I trouble you to cook up an ipv6 version of this patch?
Here's my tentative version.
On Mon, 30 Apr 2007 19:56:04 +0900 (JST)
YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] (at Mon, 30 Apr 2007 00:26:43 -0700 (PDT)),
David Miller [EMAIL PROTECTED] says:
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
Eric, I've applied this, thanks
In article [EMAIL PROTECTED] (at Mon, 30 Apr 2007 14:47:15 +0200), Eric
Dumazet [EMAIL PROTECTED] says:
Also, I am not sure we need to use all 128 bits of IPV6 address, maybe the 64
low order bits are enough ?
Well, maybe, but in IPv6, auto-configured addresses on an interface have
the same
YOSHIFUJI Hideaki / 吉藤英明 a écrit :
In article [EMAIL PROTECTED] (at Mon, 30 Apr 2007 14:47:15 +0200), Eric Dumazet
[EMAIL PROTECTED] says:
Also, I am not sure we need to use all 128 bits of IPV6 address, maybe the 64
low order bits are enough ?
Well, maybe, but in IPv6, auto-configured
Hi Eric and all,
Thanks a lot. However, some chunks still resisted to apply, the manual
patching worked. I tested and the results are more than satisfactory.
Not just the reception part became faster, but also the bind calls. The
gain is especially significant when increasing the hash table size.
On Thu, 29 Mar 2007 21:24:31 +0200
Zacco [EMAIL PROTECTED] wrote:
Hi,
Thanks for the patch. I almost dare not confess that I don't know which
version to apply to. I tried 3 different ones (2.6.19-r5-gentoo,
2.6.20.1 and 2.6.21-rc4), but in the best case at least two hunks
failed.
Hi,
Thanks for the patch. I almost dare not confess that I don't know which
version to apply to. I tried 3 different ones (2.6.19-r5-gentoo,
2.6.20.1 and 2.6.21-rc4), but in the best case at least two hunks
failed. Nevertheless, I applied the patches manually. In each case, UDP
stopped
Eric Dumazet a écrit :
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
Zacco a écrit :
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 dont understand why you need many sockets then.
A single socket should be enough.
I
Zacco a écrit :
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.
When the receiver and sender are on the same machine, the sendto() pass the
packet to
From: Zacco [EMAIL PROTECTED]
Date: Wed, 21 Mar 2007 22:53:13 +0100
Do you think there is interest in such a modification? If so, how could
we go on with it?
The best thing you can do is hash on both saddr/sport. In order
to handle the saddr==0 case the socket lookup has to try two
lookups,
On Wed, 21 Mar 2007 18:15:10 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 21 Mar 2007 23:12:40 +0100
I chose in this patch to hash UDP sockets with a hash function that take
into
account both their port number and address : This has
Hi,
David Miller wrote:
From: Zacco [EMAIL PROTECTED]
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
Zacco a écrit :
Hi,
David Miller wrote:
From: Zacco [EMAIL PROTECTED]
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
Hi Baruch and all,
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
From: Zacco [EMAIL PROTECTED]
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
* Zaccomer Lajos [EMAIL PROTECTED] [070306 17:39]:
Hi,
I'm playing around with a simulation, in which many thousands of IP
addresses (on interface aliases) are used to send/receive TCP/UDP
packets. I noticed that the time of send/sendto increased linearly
with the number of file
Zaccomer Lajos [EMAIL PROTECTED] writes:
I'm playing around with a simulation, in which many thousands of IP
addresses (on interface aliases) are used to send/receive TCP/UDP
Something seems to be wrong with your emailer. It adds a empty
line between each real line.
packets. I noticed
Hi,
Thx a lot you for the advice, I'll have a try.
And sorry for the stupid webmail, I will not use it again.
Zacco
Andi Kleen wrote:
Zaccomer Lajos [EMAIL PROTECTED] writes:
I'm playing around with a simulation, in which many thousands of IP
addresses (on interface aliases) are used
20 matches
Mail list logo
