Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Sep 2006 14:29:34 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Peter Jeremy <peterjeremy@optushome.com.au>
Cc:        freebsd-net@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: Much improved sendfile(2) kernel implementation
Message-ID:  <451285AE.5030900@freebsd.org>
In-Reply-To: <20060921075903.GD960@turion.vk2pj.dyndns.org>
References:  <4511B9B1.2000903@freebsd.org> <20060921075903.GD960@turion.vk2pj.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
> On Wed, 2006-Sep-20 23:59:13 +0200, Andre Oppermann wrote:
>> I have rewritten kern_sendfile() to work in two loops, the inner which turns
>> as many pages into mbufs as it can up to the free send socket buffer space.
> 
> The 64K blocks sounds good but how does this interact with TCP slow
> start?  Is there the possibility that a couple (for some reasonably
> large value of 'couple') of TCP connections slowly accepting a file
> could eat all the mbuf space?

This danger is and has been always present.  This normal socket behavior
and happens no matter which method (write or sendfile) you use.  Even the
current sendfile(2) fills the socket buffer when the connection is in slow
start.  It just spends more CPU once the connection is going and getting
throughput (and it doesn't make much use of TSO there).

-- 
Andre



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?451285AE.5030900>