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

From: Andre Oppermann (andre_at_freebsd.org)
Date: 03/06/04

  • Next message: HarryH: "BSD 4.9 Ethernet Driver?" 
    Date: Sat, 06 Mar 2004 02:49:45 +0100
To: "Jin Guojun [DSD]" <j_guojun@lbl.gov>

    "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
_______________________________________________
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"
  • Next message: HarryH: "BSD 4.9 Ethernet Driver?"

    Relevant Pages

    • Re: sender side Sbuf/Mbuf patch for 5.2.x is ready
      ... > For more information about this patch, ... you are talking about the mtu in your Note file. ... MTU is not directly relevant for TCP transfers but the MSS is. ...
      (freebsd-net)
    • Re: [PATCH] [TRIVIAL] spelling fix in various files: preferred -> preferred
      ... This patch doesn't apply cleanly to mainline any more. ... * Set the card to the preferred ring speed. ... * Some would have prefered functions defined this way: ... Any interrupts associated with the canceled transfers ...
      (Linux-Kernel)
    • Re: [9fans] patch/create problem (error?)
      ... I created a patch yesterday and it worked fine. ... however, if i use a lower mtu, things work fine. ... blocks icmp messages. ... i wrote a program called cpmtu. ...
      (comp.os.plan9)
    • Re: 2.6.11, USB: High latency?
      ... > The issue with IN transfers is that microframe scheduling is ... ... > the relevant EHCI data structures are almost as irregular as the USB trees ... > enough to repost them against current BK (they include the patch above). ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] input: Add support for the TSC2003 controller.
      ... It looks to me that this chip is not much different from ... Attached is a patch that fixes things for me. ... The attached patch uses a struct work_struct to schedule the I2C ... transfers so they are executed in non-interrupt context. ...
      (Linux-Kernel)