From owner-freebsd-net@FreeBSD.ORG Fri Mar 5 17:49:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3CA716A4CE for ; Fri, 5 Mar 2004 17:49:52 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA31143D3F for ; Fri, 5 Mar 2004 17:49:51 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 55112 invoked from network); 6 Mar 2004 01:49:51 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 Mar 2004 01:49:51 -0000 Message-ID: <40492E39.1B0D0C7B@freebsd.org> Date: Sat, 06 Mar 2004 02:49:45 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jin Guojun [DSD]" References: <40491DE2.1EB7707E@lbl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: performance@freebsd.org cc: net@freebsd.org Subject: Re: sender side Sbuf/Mbuf patch for 5.2.x is ready X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 01:49:52 -0000 "Jin Guojun [DSD]" wrote: > > The sender side patch for fixing Sbuf/Mbuf can be found at: > > http://dsd.lbl.gov/~jin/network/lion/patches/smbuf.patch.tbz > > Patch is for both 4.x and 5.2.x. To apply patch: ... > For more information about this patch, please refer to: > > http://dsd.lbl.gov/~jin/network/lion/content.html > and > http://dsd.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > Hopefully, we can make this into 5.3-RELEASE. > Please test and verify it. I've just looked through your website and the patch and have a couple of comments. The bottleneck you have identified and measured looks interesting. What I'm missing is a more in-depth description of the problem and what exactly your Lion implementation does. From looking over the patch it seems to include and mix debugging routines, mbuf chain optimizations and references to lion_ functions which are stale. It is not clear what is doing what. If you want this to have any chance of being included you should separate that from each other and provide them in its own patchset preferrably as unified diff (diff -u). You also have to observe the style of the surrounding code more. We have a very strict style guide and patches to existing code must be written in the same way as the surrounding code. Two more things, you are talking about the mtu in your Note file. The MTU is not directly relevant for TCP transfers but the MSS is. The MSS is the maximum payload a TCP segment/packet can transport and is always much lower than the link/path MTU. You have the MSS in the tcpcb.maxseg variable. The other things is that I assume you do file transfers at high speed since an application is probably not capable of producing 1Gbit/s geniue date for transfer. Have you checked out sendfile(2) and tested that with high speed links? The advantage of sendfile is to save the copy from userland to kernel but instead it goes directly from disk-io to mbuf. -- Andre