Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Mar 2004 19:45:08 -0800
From:      "Jin Guojun [NCS]" <j_guojun@lbl.gov>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        net@freebsd.org
Subject:   Re: sender side Sbuf/Mbuf patch for 5.2.x is ready
Message-ID:  <40494944.576A29F9@lbl.gov>
References:  <40491DE2.1EB7707E@lbl.gov> <40492E39.1B0D0C7B@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40494944.576A29F9>