Paul Mackerras wrote: > Very interesting. Can you work out where memcpy is being called on > the network data? I wouldn't have expected that.
Ok. I've some results. I done two test with different MTU. In both cases, about 0.5GB in total has been transfered over network. Large blocks. The test didn't trace a "shallow copy", where occasionally memcpy() is also in use. 1) MTU=1500 (on both host and mpc8313) * achieved throughput: 22MB/s (from mpc), 16MB/s (to mpc) * total size of copied data by memcpy() was 37.6MB * 96% of that has been copied by skb_clone(): 787758 times in blocks of 48B. * about 3% of that has been copied by skb_copy_bits(): 1013 times, the block size vary but rather bigger like 1300B. * about 1% of that has been copied by eth_header(): 80248 times in blocks of 6B (!!!!). 2) MTU=9000 (on both host and mpc8313) * achieved throughput: 50MB/s (from mpc), 44MB/s (to mpc) * total size of copied data by memcpy() was 6.4MB * 97% of that has been copied by skb_clone(): 134260 times in blocks of 48B. * 3% (whole rest) has been copied by eth_header(): 32912 times in blocks of 6B. Conclusion. Need for optimized memcpy() for blocks 48B and 6B :). Joke. I said earlier, that I got about 10% boost when I replaced memcpy() by __copy_tofrom_user(). It was the case with MTU 9000 because I work with that setting in my environment. I don't know when __copy_tofrom_user get faster than memcpy on other cpus than mpc8313, but on mpc8313 48B blocks are more suitable for __copy_tofrom_user. Dominik _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev