sender side Sbuf/Mbuf patch for 5.2.x is ready

[Jin Guojun [NCS]]

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