From: Zacco <zacco@fw.hu>
To: David Miller <davem@davemloft.net>
Cc: baruch@ev-en.org, netdev@vger.kernel.org
Subject: Re: many sockets, slow sendto
Date: Tue, 20 Mar 2007 22:59:10 +0100 [thread overview]
Message-ID: <4600592E.80605@fw.hu> (raw)
In-Reply-To: <20070319.161611.70218081.davem@davemloft.net>
Hi,
David Miller wrote:
> From: Zacco <zacco@fw.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?
thx: Zacco
next prev parent reply other threads:[~2007-03-20 21:58 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 [this message]
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
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=4600592E.80605@fw.hu \
--to=zacco@fw.hu \
--cc=baruch@ev-en.org \
--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).