All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Rick Jones <rick.jones2@hp.com>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: [PATCH] udp: extend hash tables to 256 slots
Date: Wed, 07 Oct 2009 06:43:31 +0200	[thread overview]
Message-ID: <4ACC1C73.1010506@gmail.com> (raw)
In-Reply-To: <4ACC0CDE.1020907@gmail.com>

Eric Dumazet a écrit :
> I was going to setup a bench lab, with a typical RTP mediaserver, with say
> 4000 UDP sockets, 2000 sockets exchanging 50 G.711 Alaw/ulaw
> messages per second tx and rx. (Total : 100.000 packets per second each way)
> 

Hmm, it seems we'll have too many sockets per udp hash chain unfortunatly for this
workload to show any improvement.

(~32 sockets per chain : average of 16 misses to lookup the target socket.)

David, I believe UDP_HTABLE_SIZE never changed from its initial value of 128,
defined 15 years ago. Could we bump it to 256 ?

(back in 1995, SOCK_ARRAY_SIZE was 256)

(I'll probably use 1024 value for my tests)

[PATCH] udp: extend hash tables to 256 slots

UDP_HTABLE_SIZE was initialy defined to 128, which is a bit small for several setups.
4000 active sockets -> 32 sockets per chain in average.

Doubling hash table size has a memory cost of 128 (pointers + spinlocks) for UDP,
same for UDPLite, this should be OK.

It reduces the size of bitmap used in udp_lib_get_port() and speedup port allocation.
#define PORTS_PER_CHAIN (65536 / UDP_HTABLE_SIZE) -> 256 bits instead of 512 bits

Use CONFIG_BASE_SMALL to keep hash tables small for small machines.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/include/linux/udp.h b/include/linux/udp.h
index 0cf5c4c..8aaa151 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -45,7 +45,7 @@ static inline struct udphdr *udp_hdr(const struct sk_buff *skb)
 	return (struct udphdr *)skb_transport_header(skb);
 }
 
-#define UDP_HTABLE_SIZE		128
+#define UDP_HTABLE_SIZE		(CONFIG_BASE_SMALL ? 128 : 256)
 
 static inline int udp_hashfn(struct net *net, const unsigned num)
 {

  reply	other threads:[~2009-10-07  4:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06 23:08 [RFC net-next-2.6] net: speedup sk_wake_async() Eric Dumazet
2009-10-07  0:28 ` David Miller
2009-10-07  0:42 ` Rick Jones
2009-10-07  3:37   ` Eric Dumazet
2009-10-07  4:43     ` Eric Dumazet [this message]
2009-10-07  5:29       ` [PATCH] udp: extend hash tables to 256 slots David Miller
2009-10-07  5:33         ` Eric Dumazet
2009-10-07  5:35           ` David Miller
2009-10-07 10:37         ` [PATCH net-next-2.6] udp: dynamically size hash tables at boot time Eric Dumazet
2009-10-07 10:47           ` David Miller
2009-10-08  5:01           ` David Miller
2009-10-07 15:53     ` [RFC net-next-2.6] net: speedup sk_wake_async() Rick Jones

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=4ACC1C73.1010506@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.