Date: Mon, 14 Dec 1998 09:28:30 +0100 (CET) From: List User <listuser@netspace.net.au> To: freebsd-stable@FreeBSD.ORG Message-ID: <199812140828.JAA10763@doorway.home.lan>
next in thread | raw e-mail | index | archive | help
Newsgroups: freebsd.stable
Path: root
From: Michael Robinson <robinson@netrinsics.com>
Subject: MLEN < write length < MINCLSIZE "bug"
Received: (from robinson@localhost)
by netrinsics.com (8.8.8/8.8.7) id OAA00472
for freebsd-stable@freebsd.org; Mon, 14 Dec 1998 14:37:09 GMT
(envelope-from robinson)
To: freebsd-stable
Sender: owner-freebsd-stable@FreeBSD.ORG
Organization: Private News Host
Precedence: bulk
Message-ID: <199812141437.OAA00472@netrinsics.com>
Delivered-To: vmailer-stable@freebsd.org
X-Uidl: 3fc5e9bf08bf023b8c6c90456e2c301d
X-Loop: FreeBSD.ORG
Date: Mon, 14 Dec 1998 14:37:09 GMT
I previously wrote:
>Which brings us back to where we started. Squid and ORBit (at the very
>least) exhibit severe performance degradation with the current
>MLEN < write length < MINCLSIZE bug. There isn't an open PR (that I can
>find), and the Squid FAQ advocates a kernel patch that breaks X Windows
>(among other things).
>
>If someone who is familiar with the fundamental problem could explain it
>to me in more detail, along with some possible solutions, I could try to
>play with it.
Well, no one explained it to me, but I played with it anyway. I've come to
the following conclusions:
1. This isn't a bug. It's a performance tradeoff of memory efficiency
(allocating an mbuf cluster) versus protocol efficiency (sending
two packets).
2. MINCLSIZE is an arbitrary value. It only serves to set the threshold
for the above performance tradeoff.
3. For certain applications which are latency-sensitive and send many
packets in the MLEN < len < MINCLSIZE range over TCP (such as SQUID
and IIOP), the current threshold setting is completely inappropriate.
However, for other applications (such as large FTP servers), reducing
MINCLSIZE would be completely inappropriate.
4. One solution is to make MINCLSIZE a kernel config option. This is ugly,
but simple to implement and relatively non-intrusive.
5. Another solution is to add a socket option, and modify kern/uipc_socket.c
something like this:
- if (resid >= MINCLSIZE) {
+ if ((resid >= MINCLSIZE) ||
+ ((resid > MLEN) && (so->so_options & SO_NOSPLIT))) {
MCLGET(m, M_WAIT);
if ((m->m_flags & M_EXT) == 0)
goto nopages;
mlen = MCLBYTES;
len = min(min(mlen, resid), space);
} else {
With a socket option, applications that wanted low latency (at the
expense of more memory usage) could specify that on a per-socket basis.
This is less ugly, but requires extensive changes to documentation,
header files, and application software.
6. My current solution is just to fix it in sys/mbuf.h:
#define MINCLSIZE (MHLEN + 1) /* smallest amount to put in cluster */
This is an ugly solution for general use, but it works well enough for
me.
-Michael Robinson
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812140828.JAA10763>