sender side Sbuf/Mbuf patch for 5.2.x is ready
Jin Guojun [NCS]
j_guojun at lbl.gov
Fri Mar 5 19:43:54 PST 2004
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
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
The Note is "For future development:" for LION which has nothing to do with
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
More information about the freebsd-performance