From owner-freebsd-performance@FreeBSD.ORG Fri Mar 5 19:43:53 2004 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5F5F16A4CE; Fri, 5 Mar 2004 19:43:53 -0800 (PST) Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42EF643D31; Fri, 5 Mar 2004 19:43:53 -0800 (PST) (envelope-from j_guojun@lbl.gov) Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) ESMTP id i263j8CJ000424; Fri, 5 Mar 2004 19:45:08 -0800 (PST) (envelope-from j_guojun@lbl.gov) Sender: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net Message-ID: <40494944.576A29F9@lbl.gov> Date: Fri, 05 Mar 2004 19:45:08 -0800 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.9-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: Andre Oppermann References: <40491DE2.1EB7707E@lbl.gov> <40492E39.1B0D0C7B@freebsd.org> 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-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 03:43:54 -0000 Andre Oppermann wrote: > "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. It looks like that you did not read the email closely. Only very short and clear patches are for SBuf/Mbuf in mbuf.sb/ directory. Do not look into other directories which are for LION project, not for TCP. LION is not for TCP/IP. LION is totally different network architecture, but it contains backward compatibility for TCP. That is why there is some code there for this purpose. So, do not be confused. > > 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 Note is "For future development:" for LION which has nothing to do with TCP. So there is no MSS or tcpcb.maxseg etc. > > 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. A few things are concerned here. (1) generic I/O for applications. New network architecture has to consider applications that still read//write. (2) computational data may not be on disk but in memory. Scientific programmers may not know mmap. (3) 1 Gbits/s is past. New goal is 100Gbits/s or 1Tbits/s in 200 ms RTT, and wireless networks. -Jin