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

[Andre Oppermann]

"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.

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

-- 
Andre