lkml.org 
[lkml]   [1999]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: zero-copy TCP fileserving
    Bjorn Wesen wrote:
    >
    > On Thu, 3 Jun 1999, Richard B. Johnson wrote:
    > > > But for the hardware I'm running this on, a checksum + copy takes at least
    > > > twice the time as a checksum (simple - read vs read/write). And this is
    > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > >
    > > No, not at all. With memory-to-memory copy, you are I/O bound. With any
    > > CPU that runs faster than memory access (anything faster than a
    > > 486-DX/66), you get the checksumming for free if the code is properly
    > > written, which Linux's checksum while copy sees to be.

    > If your CPU needs to read 100 MByte and then write it back to ram, it does
    > take twice the time as just reading it.

    no, Richard is right - on modern cpus the additional writes don't slow
    you down that much (eg on pii - only ~7% for fullsized eth frames).

    TIME-N+S TIME32 TIME33 TIME1480 TIMEXXXX CKSUM FUNCTION ( rdtsc_overhead=2 null=-1 )
    20320 8205 8987 17502 18492 : 51252 csum_partial_686as1s
    22109 9978 13303 18693 25684 : 51252 csum_partial_copy_generic_686as2
    17609 12194 12748 10207 22893 : 0 kernel_memcpy686as2


    > Fact: our HW, while sending TCP on a 100 mbit/s ethernet, spends 70% of
    > the time in csum_partial_copy. I'd be surprised if the performance of the
    > transfers wouldn't go up quite alot if that call was eliminated.

    what hw is that?


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:8.683 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site