Rick, In addition to showing improved throughput, the CPU utilization(service demand) also went down. But one of the CPUs was running at full utilization. For eg. without LRO, the CPU "idle" times on the 4 CPUs were 39,43,8,12(average 25% idle). With LRO, it was 48/0/46/47(average 35% idle).
Regards, Ravi -----Original Message----- From: Rick Jones [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 4:08 PM To: Ravinandan Arakali Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH 2.6.16-rc1] S2io: Large Receive Offload (LRO) feature for Neterion (s2io) 10GbE Xframe PCI-X and PCI-E NICs Ravinandan Arakali wrote: > Rick, > This is the basic implementation I submitted. I will try and include support > for timestamp option and resubmit. > I did not did understand your other comments about "service demand". Sorry, that's a netperfism - netperf can report the "service demand" measured during a test - it is basically the quantity of CPU consumed per unit of work performed. Lower is better. For example: languid:/opt/netperf2# src/netperf -H 192.168.3.212 -c -C TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.3.212 (192.168.3.212) port 0 AF_INET Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB 87380 16384 16384 10.00 940.96 17.01 47.96 2.962 8.351 In the test above, the sender consumed nearly 3 microseconds of CPU time to transfer a KB of data, and the reciever consumed nearly 8.4 rick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
