My test is almost same with Alexander. But we only use one rx queue.
Sent from Samsung Mobile -------- Original message -------- From: Prashant Upadhyaya <prashant.upadhy...@aricent.com> Date: 11/05/2013 6:41 AM (GMT-08:00) To: Alexander Belyakov <abelyako at gmail.com>,Olivier MATZ <olivier.matz at 6wind.com> Cc: dev at dpdk.org Subject: Re: [dpdk-dev] Surprisingly high TCP ACK packets drop counter Hi Alexander, I am also wondering like Olivier ? yours is a nice testcase and setup, hence requesting the information below instead of spending a lot of time reinventing the test case at my end. If you have the time on your side, it would be interesting to know what is the number of packets per second received inside your application on each of your 4 queues individually in both the usecases ? with and without RSC. I am just wondering (since your throughput almost exactly goes down 50 %), that your apparent randomization of packets may not really be random enough and with RSC enabled the packets are coming on two queues only or there might be an uneven distribution. Or it may well be that NIC gets overwhelmed with RSC processing and that brings down the throughput. Either way, it would be very interesting to get stats for packets per second on each queue in both the usecases. Regards -Prashant From: Alexander Belyakov [mailto:abely...@gmail.com] Sent: Tuesday, November 05, 2013 5:29 PM To: Olivier MATZ Cc: Prashant Upadhyaya; dev at dpdk.org Subject: Re: [dpdk-dev] Surprisingly high TCP ACK packets drop counter Hello, The role of RSC is to reassemble input TCP segments, so it is possible that the number of TCP packets sent to the DPDK is lower but some packets may contain more data. Can you confirm that? I don't think out test case can answer your question, because all generated TCP ACK packets were as small as possible (no tcp payload at all). Source IPs and ports were picked at random for each packet, so most of (adjacent) packets belong to different TCP sessions. In my opinion, this mechanism should be disabled by default because it could break PMTU discovery on a router. However it could be useful for somebody doing TCP termination only. I was thinking about new rte_eth_rxmode structure option: @@ -280,6 +280,7 @@ struct rte_eth_rxmode { hw_vlan_strip : 1, /**< VLAN strip enable. */ hw_vlan_extend : 1, /**< Extended VLAN enable. */ jumbo_frame : 1, /**< Jumbo Frame Receipt enable. */ + disable_rsc : 1, /**< Disable RSC (receive side convalescing). */ hw_strip_crc : 1; /**< Enable CRC stripping by hardware. */ }; Regards, Alexander =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===============================================================================
