From owner-freebsd-net  Mon Dec 14 21:52:08 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id VAA15737
          for freebsd-net-outgoing; Mon, 14 Dec 1998 21:52:08 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA15732;
          Mon, 14 Dec 1998 21:52:07 -0800 (PST)
          (envelope-from fenner@parc.xerox.com)
Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <55377(4)>; Mon, 14 Dec 1998 21:52:01 PST
Received: (from fenner@localhost)
	by mango.parc.xerox.com (8.8.8/8.8.8) id VAA17801;
	Mon, 14 Dec 1998 21:52:00 -0800 (PST)
	(envelope-from fenner)
Date: Mon, 14 Dec 1998 21:52:00 PST
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <199812150552.VAA17801@mango.parc.xerox.com>
To: fenner@parc.xerox.com, robinson@netrinsics.com
Subject: Re: MLEN < write length < MINCLSIZE "bug"
Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG
In-Reply-To: <199812151340.NAA07127@netrinsics.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

You misunderstand.  The fix is to accumulate mbufs in a chain until either
a) The protocol gets all of the data that it wanted, or
b) All of the data that the user has provided has been copied into mbufs.

(b) is what sosend() used to do.  The URL referenced (the one with
"vanj88" in it) describes why sosend() was changed to use only a single
mbuf at a time, but this performance problem was not envisioned at
the time.

  Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message