Date: Wed, 28 Nov 2007 21:15:06 -0800 From: "Kip Macy" <kip.macy@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org>, Kip Macy <kmacy@freebsd.org> Subject: Re: PERFORCE change 129544 for review Message-ID: <b1fa29170711282115i57ffe985qbebc7c5f4a663154@mail.gmail.com> In-Reply-To: <20071126115044.J65286@fledge.watson.org> References: <200711260527.lAQ5RNSw090238@repoman.freebsd.org> <20071126115044.J65286@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 26, 2007 3:55 AM, Robert Watson <rwatson@freebsd.org> wrote: > > On Mon, 26 Nov 2007, Kip Macy wrote: > > > http://perforce.freebsd.org/chv.cgi?CH=129544 > > > > Change 129544 by kmacy@kmacy:storage:toestack on 2007/11/26 05:26:43 > > > > disable merging of data into existing mbufs if > > new SB_TOE flag is set > > One of the reasons we compact socket buffers with TCP and other stream > protocols is that if you're dealing with an application/protocol that spits > out data in small chunks (i.e., a series of printfs) and nagel is disabled, > you end up with a series of packets that make quite inefficient use of mbufs, > as the space wasted per chunk of data is significant. Not only that, we bill > for space in socket buffers based on the space held by the full mbuf, not just > the data in the mbuf when it comes to socket buffer resource limits, so you > can rapidly fill up socket buffer limits without compaction in this type of > scenario. I'm not sure which protocols this would affect, but I'd imagine > that RPC-like protocols supporting asynchronous operation (so that you get a > series of replies and responses in flight at once) might be relevant, such as > IMAP. > > On an unrelated not, if we want a non-coalescing modes for socket bufferss, we > should probably also give it a name like "SB_NOCOALESCE" rather than something > TOE-specific. > I agree that making it toe specific is somewhat misleading. I actually think I'll be able to fix my code so that it can cope with data being added to the end of a cluster or mbuf that has already been transmitted. If so, I won't need to pull this along when I bring TOE support into CVS. Thanks for the feedback. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170711282115i57ffe985qbebc7c5f4a663154>