DPDK patches and discussions
 help / color / mirror / Atom feed
From: Prashant Upadhyaya <prashant.upadhyaya@aricent.com>
To: Alexander Belyakov <abelyako@gmail.com>,
	Olivier MATZ <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Surprisingly high TCP ACK packets drop counter
Date: Tue, 5 Nov 2013 20:10:41 +0530	[thread overview]
Message-ID: <C7CE7EEF248E2B48BBA63D0ABEEE700C45DF9E40F4@GUREXMB01.ASIAN.AD.ARICENT.COM> (raw)
In-Reply-To: <CAAQJX_Q9cOsKspauRMC9aJwAR+o3FhztxsiT4cdBtandJLsE9Q@mail.gmail.com>

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@gmail.com]
Sent: Tuesday, November 05, 2013 5:29 PM
To: Olivier MATZ
Cc: Prashant Upadhyaya; dev@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.
===============================================================================

  reply	other threads:[~2013-11-05 14:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 13:43 Alexander Belyakov
2013-11-01 14:54 ` Wang, Shawn
2013-11-01 15:14   ` Thomas Monjalon
2013-11-02  5:32   ` Prashant Upadhyaya
2013-11-03 20:20   ` Alexander Belyakov
2013-11-04  3:06     ` Prashant Upadhyaya
2013-11-05  9:29       ` Alexander Belyakov
2013-11-05 10:10         ` Olivier MATZ
2013-11-05 11:59           ` Alexander Belyakov
2013-11-05 14:40             ` Prashant Upadhyaya [this message]
2013-11-05 17:03               ` Wang, Shawn
2013-11-06  8:42               ` Alexander Belyakov
2013-11-02  5:29 ` Prashant Upadhyaya
2013-11-03 20:32   ` Alexander Belyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C7CE7EEF248E2B48BBA63D0ABEEE700C45DF9E40F4@GUREXMB01.ASIAN.AD.ARICENT.COM \
    --to=prashant.upadhyaya@aricent.com \
    --cc=abelyako@gmail.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).