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>