From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by dpdk.org (Postfix) with ESMTP id B86AF58E9 for ; Tue, 5 Nov 2013 18:03:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=xingbow@amazon.com; q=dns/txt; s=amazon201209; t=1383671077; x=1415207077; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:mime-version; bh=TrkdTE8vPNkJevVPZCeGHXX1vCP+5BCNKRxlvYLSx/0=; b=vgKXCxXyZEJbe1uvOPGApANrjtZNiiSHRWPlqqrcESEwQ+9Cz5b6j6I7 IhOTFn6/R+vc4VwjQSddHdFhAN11Brrg5MIdD2WzH2uafxp8pnbf2s+5F bcJ8j7BT+oWMoY7CD5pyKna+MKG2a+gTOLsVPMNx0AGSSYUexEFtFOdO2 8=; X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208,217";a="607309601" Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Nov 2013 17:03:38 +0000 Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com [10.185.137.58]) by smtp-in-9003.sea19.amazon.com (8.14.7/8.14.7) with ESMTP id rA5H3bFA030087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 Nov 2013 17:03:37 GMT Received: from EX10-MBX-31007.ant.amazon.com ([fe80::dc2d:ebf:d4a1:fac]) by ex10-hub-9001.ant.amazon.com ([::1]) with mapi id 14.02.0342.003; Tue, 5 Nov 2013 09:03:15 -0800 From: "Wang, Shawn" To: Prashant Upadhyaya , Alexander Belyakov , Olivier MATZ Thread-Topic: [dpdk-dev] Surprisingly high TCP ACK packets drop counter Thread-Index: AQHO1whjRxNd259ED0ycA7IZkDyueZoQdm4AgAQGCICAAHE8AIAB/YiAgAALTwCAAB5jgIAALR+A//+huR8= Date: Tue, 5 Nov 2013 17:03:15 +0000 Message-ID: <09ra4ke5e9nkvpn28el33njn.1383670987412@email.android.com> References: <5278C412.4000204@6wind.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Precedence: Bulk Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Surprisingly high TCP ACK packets drop counter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Reply-To: "Wang, Shawn" List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:03:44 -0000 My test is almost same with Alexander. But we only use one rx queue. Sent from Samsung Mobile -------- Original message -------- From: Prashant Upadhyaya Date: 11/05/2013 6:41 AM (GMT-08:00) To: Alexander Belyakov ,Olivier MATZ Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Surprisingly high TCP ACK packets drop counter Hi Alexander, I am also wondering like Olivier =96 yours is a nice testcase and setup, he= nce requesting the information below instead of spending a lot of time rein= venting 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 o= f your 4 queues individually in both the usecases =96 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 mi= ght be an uneven distribution. Or it may well be that NIC gets overwhelmed with RSC processing and that br= ings down the throughput. Either way, it would be very interesting to get stats for packets per secon= d 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 conval= escing). */ hw_strip_crc : 1; /**< Enable CRC stripping by hardware= . */ }; Regards, Alexander =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D