From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: ak@muc.de, netdev@oss.sgi.com, mostrows@styx.uwaterloo.ca
Subject: Re: [PATCH] Increase snd/rcv buffers in pppoe
Date: Mon, 23 Feb 2004 10:26:13 -0800 [thread overview]
Message-ID: <20040223102613.33838132.davem@redhat.com> (raw)
In-Reply-To: <20040223.203843.04073965.yoshfuji@linux-ipv6.org>
Wait, I have an idea.
I was going to suggest ifdef'ing this change for 64-bit, but there is an even
nicer way to do this and it avoids the magic number argument we're having right
now too.
Let's compute this for _real_, as some kind of function on sizeof(struct sk_buff)
For example, the overhead of N 1-byte packets.
Andi has made a real observation in that various areas of performance are sensitive
to the snd/rcv buffer size, and the values we choose are inherently tied to the
size of struct sk_buff. So whatever random value we choose today, could be useless
and cause bad performance the next time we change struct sk_buff in some way.
The proposal I make intends to avoid this endless tweaking.
Two more observations while grepping for SK_{R,W}MEM_MAX.
1) IPV4 icmp sents sk_sndbuf of it's sockets to "2 * SK_WMEM_MAX", that's not
what it really wants. What it really wants is enough space to hold
~2 full sized IPV4 packets, roughly 2 * 64K + struct sk_buff overhead
and thus that is what it should be using there.
2) IPV6 icmp does the same as ipv4, except this value is even more wrong there
especially considering jumbograms. With current code, sending a jumbogram
ipv6 icmp packet would simply fail, and I wonder if anyone has even tried
this.
I'll cook something up to address all of this and it's going to go into 2.4.x as
well.
next prev parent reply other threads:[~2004-02-23 18:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-22 23:47 [PATCH] Increase snd/rcv buffers in pppoe Andi Kleen
2004-02-23 7:26 ` David S. Miller
2004-02-23 10:53 ` Andi Kleen
2004-02-23 11:01 ` YOSHIFUJI Hideaki / 吉藤英明
2004-02-23 11:16 ` Andi Kleen
2004-02-23 11:38 ` YOSHIFUJI Hideaki / 吉藤英明
2004-02-23 18:26 ` David S. Miller [this message]
2004-02-23 20:12 ` Andi Kleen
2004-02-23 21:32 ` David S. Miller
2004-02-26 19:49 ` Andi Kleen
2004-02-26 20:42 ` David S. Miller
2004-02-26 20:52 ` Andi Kleen
2004-02-26 22:03 ` Andi Kleen
2004-02-26 22:22 ` David S. Miller
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=20040223102613.33838132.davem@redhat.com \
--to=davem@redhat.com \
--cc=ak@muc.de \
--cc=mostrows@styx.uwaterloo.ca \
--cc=netdev@oss.sgi.com \
--cc=yoshfuji@linux-ipv6.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).