The request-response test case is used for testing.
A test stand has two hosts: a client and a server.
Client: Xeon X7560 (4 cpu * 8 cores * 2 threads), RAM 256Gb, RHEL 6
Server: Xeon X7550 (4 cpu * 8 cores * 2 threads), RAM 128Gb, RHEL 6 with
custom kernel (CONFIG_NR_CPUS=4)
The server side configuration:
* Interrupts are bound to CPUs.
# cpu=0; for i in `cat /proc/interrupts | grep eth4-Tx | awk '{ print $1
}'`; do irq=`echo ${i/:/}`; echo $cpu > /proc/irq/${irq}/smp_affinity_list;
let cpu++; done
* Execute netserver
# ./netperf-2.6.0/src/netserver
The following command is executed for testing on the client side:
SERVER_IP=192.168.125.1; for i in `seq 1 128`; do ./src/netperf -H
$SERVER_IP -t TCP_RR -v 0 -l 10 -- -r 1024 & done | awk ' { p += $1; print
$1 } END { print p } '
This command executes netperf 128 times, then summarize all results.
I found that this test returns 372293 req/sec without a problematic patch
and only 334911 req/sec with this patch. A degradation is about 10%.
commit 1d1a79b5b94b0aa84e1e78dd9acdcffb12274848
Author: Jacob Keller <jacob.e.kel...@intel.com>
Date: Tue May 22 06:18:08 2012 +0000
ixgbe: Check PTP Rx timestamps via BPF filter
This patch fixes a potential Rx timestamp deadlock that causes the Rx
timestamping to stall indefinitely. The issue could occur when a PTP
packet is
timestamped by hardware but never reaches the Rx queue. In order to
prevent a
permanent loss of timestamping, the RXSTMP(L/H) registers have to be
read to
unlock them. (This used to only occur when a packet that was timestamped
reached the software.) However the registers can't be read early
otherwise
there is no way to correlate them to the packet.
This patch introduces a filter function which can be used to determine
if a
packet should have been timestamped. Supplied with the filter setup by
the
hwtstamp ioctl, check to make sure the PTP protocol and message type
match the
expected values. If so, then read the timestamp registers (to free
them.) At
this point check the descriptor bit, if the bit is set then we know this
packet correlates to the timestamp stored in the RXTSTAMP registers.
Otherwise, assume that packet was dropped by the hardware, and ignore
this
timestamp value. However, we have at least unlocked the rxtstamp
registers for
future timestamping.
Due to the way the driver handles skb data, it cannot be directly
accessed. In
order to work around this, a copy of the skb data into a linear buffer
is
made. From this buffer it becomes possible to read the data correctly
Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com>
Reviewed-by: Richard Cochran <richardcoch...@gmail.com>
Tested-by: Phil Schmitt <phillip.j.schm...@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com>
# lsmod
Module Size Used by
fuse 77814 0
netconsole 14465 0
ebt_among 12643 1
ebtable_filter 12827 1
ebtables 30831 1 ebtable_filter
binfmt_misc 17424 1
joydev 17457 0
coretemp 13529 0
kvm_intel 136052 0
kvm 407763 1 kvm_intel
crc32c_intel 12858 0
microcode 19340 0
pcspkr 12718 0
ixgbe 200398 0
mdio 13398 1 ixgbe
i2c_i801 17765 0
i2c_core 34045 1 i2c_i801
lpc_ich 17061 0
mfd_core 13145 1 lpc_ich
i7core_edac 23499 0
edac_core 51035 1 i7core_edac
igb 158748 0
dca 14601 2 ixgbe,igb
ptp 18413 2 ixgbe,igb
pps_core 18595 1 ptp
megaraid_sas 81926 4
Ask me, if you will need more information. Sorry, if it is a wrong alarm.
Thanks.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
