From: Zacco <zacco@fw.hu>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: David Miller <davem@davemloft.net>,
baruch@ev-en.org, netdev@vger.kernel.org
Subject: Re: many sockets, slow sendto
Date: Thu, 29 Mar 2007 21:24:31 +0200 [thread overview]
Message-ID: <460C126F.7050303@fw.hu> (raw)
In-Reply-To: <4601ADD8.8040500@cosmosbay.com>
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 working. I guess, you checked the patch and worked. I don't
think I made a mistake in the manual copy, and it seems unlikely that
your patch interfered with other parallel changes in the kernel - but,
I'm just guessing ...
I think, I'd better send you the spec and code, as you suggested that
first we have a common understanding of the issue. I must have failed in
passing the point. I'm removing irrelevant stuff, and I send it to you
as soon as I can (sorry for my long delays).
thx a lot,
Zacco
Eric Dumazet wrote:
> 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 thousands of elements. Not that good, isnt it ? :(
>
> In case you want to try, here is a patch that could help you :)
>
> [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. Processing of incoming packets is very expensive,
> because the whole chain must be examined to find the best match.
>
> 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 a
> drawback because we need two lookups : one with a given address, one
> with a wildcard (null) address.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
next prev parent reply other threads:[~2007-03-29 19:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 15:08 many sockets, slow sendto Zaccomer Lajos
2007-03-06 18:20 ` Baruch Even
2007-03-19 23:10 ` Zacco
2007-03-19 23:16 ` David Miller
2007-03-20 21:59 ` Zacco
2007-03-20 22:48 ` Eric Dumazet
2007-03-21 21:53 ` Zacco
2007-03-21 22:24 ` Eric Dumazet
2007-03-21 23:26 ` Eric Dumazet
2007-03-22 1:14 ` David Miller
2007-03-21 22:12 ` Eric Dumazet
2007-03-22 1:15 ` David Miller
2007-03-22 6:43 ` Eric Dumazet
2007-03-29 19:24 ` Zacco [this message]
2007-03-30 13:10 ` Eric Dumazet
2007-04-22 12:34 ` Zacco
2007-04-30 7:26 ` David Miller
2007-04-30 10:56 ` YOSHIFUJI Hideaki / 吉藤英明
2007-04-30 12:47 ` Eric Dumazet
2007-04-30 19:43 ` YOSHIFUJI Hideaki / 吉藤英明
2007-04-30 19:59 ` Eric Dumazet
2007-03-06 19:23 ` Andi Kleen
2007-03-06 21:28 ` Zacco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=460C126F.7050303@fw.hu \
--to=zacco@fw.hu \
--cc=baruch@ev-en.org \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).