From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-nfs@vger.kernel.org, neilb@suse.de
Subject: Re: [PATCH] sunrpc: make warning in svc_check_conn_limits() more generic
Date: Wed, 15 Oct 2008 16:21:02 -0400 [thread overview]
Message-ID: <20081015202102.GC5038@fieldses.org> (raw)
In-Reply-To: <20081015081457.56ef3778-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Wed, Oct 15, 2008 at 08:14:57AM -0400, Jeff Layton wrote:
> From the descriptions in those commits, it looks like the check
> in svc_check_conn_limits was intended to prevent messages from too
> many sockets overloading the receive buffers.
Aren't the receive buffers per-connection?
--b.
> We size the UDP receive buffers by the number of threads:
>
> (serv->sv_nrthreads+3) * serv->sv_max_mesg
>
> TCP receive buffers are statically sized fairly small and don't ever
> seem to change since sv_max_mesg is pretty much set at server
> creation time:
>
> 3 * serv->sv_max_mesg
>
> ...the comments in svc_tcp_recvfrom explain the reason for it.
>
> Given all of this, it seems reasonable to eliminate the check
> entirely for TCP. For UDP, it looks like we expect that 1 buffer
> can handle up to 20 connections. I'm not sure where this ratio
> comes from though...
>
> Anyone else have thoughts on this?
>
> --
> Jeff Layton <jlayton@redhat.com>
next prev parent reply other threads:[~2008-10-15 20:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-12 13:12 [PATCH] sunrpc: make warning in svc_check_conn_limits() more generic Jeff Layton
2008-09-24 21:57 ` J. Bruce Fields
2008-09-25 20:23 ` Jeff Layton
[not found] ` <20080925162315.6f29d092-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-10-15 12:14 ` Jeff Layton
[not found] ` <20081015081457.56ef3778-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-10-15 20:21 ` J. Bruce Fields [this message]
2008-10-16 0:51 ` Jeff Layton
[not found] ` <20081015205118.14de4611-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-10-16 2:08 ` NeilBrown
[not found] ` <fdcfe437d88ecb7d49ea4b2729407dc5.squirrel-eq65iwfR9nKIECXXMXunQA@public.gmane.org>
2008-10-16 13:48 ` Jeff Layton
2008-10-17 0:14 ` Neil Brown
[not found] ` <18679.55525.146056.752860-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-10-17 14:55 ` William A. (Andy) Adamson
[not found] ` <89c397150810170755r578ae723o89ab7b475b894704-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-10-17 18:29 ` J. Bruce Fields
2008-10-17 18:20 ` J. Bruce Fields
2008-10-17 18:27 ` Jeff Layton
[not found] ` <20081017142753.6485571f-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-10-17 18:29 ` J. Bruce Fields
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=20081015202102.GC5038@fieldses.org \
--to=bfields@fieldses.org \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/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.