Hi Dillan, There are a few features that could be interfering with your test. One that comes immediately to mind would be GRO. Normally it is enabled and it can be disabled via "ethtool -K ethX gro off". It is possible that it may be causing some sort of delay due to packet aggregation. One other thing you could try to verify this would be to see what happens if you send a packet with no flags set. I suspect you should see the same result if the problem is related to GRO since it will aggregate frames as long as any flag other than ack is not set.
Another possibility is that ATR sampling may be causing issues. One thing you could try is to disable ATR by enabling ntuple filtering. To do this you could use the command "ethtool -K ethX ntuple on". That would prevent samples from being taken of the TCP flow which could improve performance. Thanks, Alex On 12/24/2012 03:56 AM, 周介龙 wrote: > Hi Alex, > thanks for your reply. I used an Agilent N2X packet generator to > generate and send TCP packets. The generator could be configured to send > all kinds of network packets. I configured it to send 150 byte long TCP > packets, 7.35M packets per second (about 10Gbps). The sended TCP packets > have normal format: > EthernetHeader + IPHeader + TCPHeader + TCPPayload > > The TCP header of packets is configured as below:(every sended packet > has same configuration) > TCP Header: > Source port: [1-2000, Increment] > Destination port: [1-2000, Increment] > Sequence number 0 > Ackowledge number 0 > Data offset: 5 > Reserved: 0x00 > Code Bits: > URG: 0 > ACK: 1 > PSH: 0 > RST: 0 > SYN: 0 > FIN: 0 > Window Size: 0 > Checksum: 0x2D71 (automated, > differ from packet) > Urgent pointer: 0 > TCP options: None > > Sending packets with above configuration causes a lot of > rx_missed_error(drop) at the receiving 82599 NIC. But if I just set any > flag(in Code Bits field) other than ACK to 1, there would be no errors > or drops. > > Thanks,If any other info is needed, please let me known. > Dillan > > 在 2012-12-21 02:03:15，"Alexander Duyck" <alexander.h.du...@intel.com > <mailto:alexander.h.du...@intel.com>> 写道： >>On 12/20/2012 05:56 AM, 周介龙 wrote: >>> Hi all, >>> I am testing the receive side performance of a 82599EB NIC, using the >>> newest stable driver ixgbe3.11. When receiving 10Gbps tcp pkts with (and >>> only with) ACK flag, I found a lot of drop statistics in the result of >>> ifconfig command and rx_missed_error in the result of ethtool -S. And the >>> cpu utilized percent if less than 40%. If tcp pkts have any flag other than >>> ACK, or have any optional tcp header, the NIC would never drop any pkts. I >>> think it may be caused by RSC feature, but after disabling RSC by "ethtool >>> -C eth* rx-usecs 0" or adding MACRO "-DIXGBE_NO_HW_RSC" in Makefile, the >>> NIC still drops pkts. Also, the RFCTL.RSC_DIS register can not be set to 1. >>> I have also run the same test on different motherboards, CPUs, kernels, and >>> drivers, and got the same result... This problem has been puzzling me for a >>> few months, is there any way to solve it? >>> Thanks, >>> Dillan Zhou >>> >> >>Hi Dillan, >> >>It would help if you could explain your test setup. For example how is >>it you are generating the TCP frames with the ACK flag set? Also what >>rate is it you are sending these packets at? >> >>Thanks, >> >>Alex > > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ 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
