From owner-freebsd-performance@FreeBSD.ORG Sat Apr 19 20:58:22 2003 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 8532037B401; Sat, 19 Apr 2003 20:58:22 -0700 (PDT) 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 9522B43FBD; Sat, 19 Apr 2003 20:58:21 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) ESMTP id h3K301o1000382; Sat, 19 Apr 2003 20:00:02 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Sender: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net Message-ID: <3EA20D31.2606389B@lbl.gov> Date: Sat, 19 Apr 2003 20:00:01 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: bj@dc.luth.se References: <200304191305.h3JD5S2F026929@dc.luth.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) 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: Sun, 20 Apr 2003 03:58:23 -0000 Not yet. I said I will send out email when it is ready. The problem is we have a significantly modified system based on 4.8-RC2. I tried to extract the only sockbut/mbuf code, but it apparently, the patch is in completed for pure 4.8 system. Somehow, it have some depenency of our new TCP stack. So, I am building two new systems, one pure 4.7 and one pure 4.8. I will extract correct patch for these system, test them, then send out another email. Thanks for the patient. -Jin Borje Josefsson wrote: > Hmm. I'm not sure if I misunderstood if this was ready for another test > run or not. Anyhow - I took the new patch .tgz (which, btw, still had > tcp_input.p in it). I applied the patches (except tcp_input) and tested. > > Now I get: > > Panic: bad cur_off > 00000 m_p 0xc0a7f400 0xc0a7f400 my_off 0 1448 cc 3407144 > > As usual, I'm willing to test more when there are an update available. > > --Börje > > On Fri, 18 Apr 2003 13:04:24 PDT "Jin Guojun [DSD]" wrote: > > > Opps, there was a bad file -- tcp_input.p -- which is not working yet. > > Also, a patch file -- tcp_usrreq.p -- was missing. > > > > I will take the tcp_input.p out and put tcp_usrreq.p in. > > When it is finished, I will send another mail out. > > > > -Jin > > > > Borje Josefsson wrote: > > > > > On Thu, 17 Apr 2003 22:12:02 PDT "Jin Guojun [NCS]" wrote: > > > > > > > I have modified the sockbuf and mbuf operation to double the throughput over > > > > high bandwidth delay product path. > > > > > > > > The patch is available at: > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > > > > > > > The current modification is for tcp transmission only. > > > > > > > > I have adapted some code of uipc_socket2.c from Sam Leffler > > > > http://www.freebsd.org/~sam/thorpe-stable.patch > > > > > > > > for tcp receiver, but it has not been tested yet, so the tcp_input.p is empty. > > > > > > > > I ignored all record chain (m_nextpkt) related code. The details is explained at > > > > > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#BSDMbuf > > > > > > > > Once the tcp_input code is tested, I will submit the patch to bugs@freebsd.org. > > > > I may submit the patch regardless if tcp_input code works or not, because the > > > > tcp > > > > sender (server) is more important in high-speed network than the receiver > > > > (client). > > > > > > > > It is appreciated if any one can verify the patch and provide feedback. > > > > > > OK. I have now tried this patch on a newly-installed 4.8R. The patch > > > applied fine. When the sysctl net.inet.tcp.liondmask is unset, everything > > > seems OK, but when setting it to 7 (as specified with the patch > > > instructions) i get: > > > > > > Fatal trap 12: page fault while in kernel mode. > > > (I could write down all the stuff on addresses etc if it makes sense) > > > > > > when I run ttcp to test the performance. > > > > > > This is repeatable. > > > > > > I'm willing to test more, if someone provides me with some hints on what > > > to do. > > > > > > --Börje