[dpdk-dev] Surprisingly high TCP ACK packets drop counter

[Wang, Shawn]

My test is almost same with Alexander. But we only use one rx queue.


Sent from Samsung Mobile



-------- Original message --------
From: Prashant Upadhyaya <prashant.upadhyaya at 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:abelyako at 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.
===============================================================================