patch for test (Was: tcp_output starving -- is due to mbuf get delay?)

[Jin Guojun [NCS]]

Now the patch is ready. It has been tested on both 4.7 and 4.8.
For 4.7, one has to manually add an empty line before the comment prior to the
tcp_output() routine. <there is no spacing between end of SYSCTL and
comment for beginning the tcp_output() in 4.7-RELEASE :-( >

Some more hints for tracing: (net.inet.tcp.liondmask is a bitmap)
bit 0-1 (value 1, 2, or 3) is for enabling tcp_output() mbuf chain modification
bit 2 (value 4) is for enabling sbappend() mbuf chain modification
bit 3 (value 8) is for tcp_input (DO NOT TRY IT, it is not ready).

bit 9 (value 512) is for enabling check routine (dump errors to /var/log/messag).

If you do have problem, set net.inet.tcp.liondmask to 512 and look what message says.
If you would like to know which part causing problem or not working properly,
set net.inet.tcp.liondmask  to 1, 2, 3 or 4 to test individual module.

    -Jin

"Jin Guojun [NCS]" wrote:

> 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 at 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