Re: sender side Sbuf/Mbuf patch for 5.2.x is ready
From: Jin Guojun [NCS] (j_guojun_at_lbl.gov)
Date: 03/06/04
- Previous message: Julian Elischer: "Re: sender side Sbuf/Mbuf patch for 5.2.x is ready"
- Maybe in reply to: Jin Guojun [DSD]: "sender side Sbuf/Mbuf patch for 5.2.x is ready"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 05 Mar 2004 19:45:08 -0800 To: Andre Oppermann <andre@freebsd.org>
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
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"
- Previous message: Julian Elischer: "Re: sender side Sbuf/Mbuf patch for 5.2.x is ready"
- Maybe in reply to: Jin Guojun [DSD]: "sender side Sbuf/Mbuf patch for 5.2.x is ready"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
