RE: [UPDATE] Fresh zerocopy patch on kernel.org
> Malcolm Beattie writes: > > Alexey has mailed me suggesting the problem may be that netfilter > > is turned on. > > Oh yes, netfilter being enabled will cause some performance > degradation, that is for sure. Do you think that netfilter being enabled would also cause a decrease in routing throughput (ie: causing packet loss)? Cheers! Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] Fresh zerocopy patch on kernel.org
Malcolm Beattie writes: > Alexey has mailed me suggesting the problem may be that netfilter > is turned on. Oh yes, netfilter being enabled will cause some performance degradation, that is for sure. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] Fresh zerocopy patch on kernel.org
David S. Miller writes: > > Malcolm Beattie writes: > > David S. Miller writes: > > > > > > At the usual place: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.1-1.diff.gz > > > > Hmm, disappointing results here; maybe I've missed something. > > As discussed elsewhere there is a %10 to %15 performance hit for > normal write()'s done with the new code. > > If you do your testing using sendfile() as the data source, you'll > results ought to be wildly different and more encouraging. I did say that the ftp test used sendfile() as the data source and it dropped from 86 MB/s to 62 MB/s. Alexey has mailed me suggesting the problem may be that netfilter is turned on. It is indeed turned on in both the 2.4.1 config and the 2.4.1+zc config but maybe it has a far higher detrimental effect in the zerocopy case. I'm currently building new non-netfilter kernels and I'll go through the exercise again. I'm confident I'll end up being impressed with the numbers even if it takes some tweaking to get there :-) --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] Fresh zerocopy patch on kernel.org
Malcolm Beattie writes: > David S. Miller writes: > > > > At the usual place: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.1-1.diff.gz > > Hmm, disappointing results here; maybe I've missed something. As discussed elsewhere there is a %10 to %15 performance hit for normal write()'s done with the new code. If you do your testing using sendfile() as the data source, you'll results ought to be wildly different and more encouraging. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] Fresh zerocopy patch on kernel.org
David S. Miller writes: > > At the usual place: > > ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.1-1.diff.gz Hmm, disappointing results here; maybe I've missed something. Setup is a Pentium II 350MHz (tusk) connected to a Pentium III 733MHz (heffalump) (both 512MB RAM) with SX fibre, each with a 3Com 3C985 NIC. Kernels compared are 2.4.1 and 2.4.1+zc (the 2.4.1-1 diff above) using acenic driver with MTU set to 9000. Sysctls set are # Raise socket buffer limits net.core.rmem_max = 262144 net.core.wmem_max = 262144 # Increase TCP write memory net.ipv4.tcp_wmem = 10 10 10 on both sides. Comparison tests done were gensink4: 10485760 (10MB) buffer size, 262144 (256K) socket buffer ftp: server does sendfile() from a 300MB file in page cache, client does read from socket/write to /dev/null in 4K chunks. 2.4.12.4.1+zc KByte/s tusk%CPU heff%CPU KByte/s tusk%CPU heff%CPU gensink4 tusk->heffalump94000 58-100 9354000 98-102 11-45 heffalump->tusk72000 86-100 46-59 7 71-9353-71 2.4.1 2.4.1+zc KByte/s KByte/s ftp heffalump->tusk 86000 62000 I was impressed with the raw 2.4.1 figures and hoped to be even more impressed with the 2.4.1+zc numbers. Is there something I'm missing or can change or do to help to improve matters or track down potential problems? --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] Fresh zerocopy patch on kernel.org
Chris Wedgwood writes: > On Tue, Jan 30, 2001 at 01:33:34AM -0800, David S. Miller wrote: > > 2) Accept TCP flags (ACK, URG, RST, etc.) for out of window packets >if truncating the data to the window would make that packet valid. >(Alexey) > > 3) Add SO_ACCEPTCONN, Unix standard wants it. (me) > > these have been feed back for 2.4.x Linus anyhow right? Yes, but I couldn't get them to him in time for 2.4.1 Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/