From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <abelyako@gmail.com>
Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com
 [IPv6:2607:f8b0:400d:c00::230])
 by dpdk.org (Postfix) with ESMTP id 51CD958E9
 for <dev@dpdk.org>; Tue,  5 Nov 2013 12:58:18 +0100 (CET)
Received: by mail-qa0-f48.google.com with SMTP id w8so961853qac.0
 for <dev@dpdk.org>; Tue, 05 Nov 2013 03:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=T9H0509KxrhllkrCnVJxWhRF/VP2W7HYuIOg4OPk+1s=;
 b=Ef0guVA+5RKKTJcgykMwKuJCXLWyslDE0stro7xb+PICC2QxZhK1Cspmxdea7+McC9
 Acay/Sez5lJrdCkwczEiK9aCWrc4jf94NUvaxGBsUipFgBppQX1RJOXJu6DvJvTIlC7U
 JECGSL6dmEivEMuJffv5lg2NFf5GXOWhjjLhBLyvcBCVFi5c14XXMO9Jvp4gmTmGF9Ix
 WLxptDXgHy8vQDrns3yUTNO4r+smSkpF0a1ahV8T076t7d/uALzU47/hod20FecEx3N3
 yI+CGKC5+kFpsiHlkBQQzy9Z4QQ/mZFa5OmCNIpQEPK1f8UPLyh9nIJXFVTX5AHrK3DH
 BCgg==
MIME-Version: 1.0
X-Received: by 10.224.120.6 with SMTP id b6mr29167518qar.11.1383652751350;
 Tue, 05 Nov 2013 03:59:11 -0800 (PST)
Received: by 10.140.27.4 with HTTP; Tue, 5 Nov 2013 03:59:11 -0800 (PST)
In-Reply-To: <5278C412.4000204@6wind.com>
References: <CAAQJX_SWNBvBDTz3o_7Wo17-redr3Sygwq4pxBMTk3oYTwFhRQ@mail.gmail.com>
 <CE990D16.3B335%xingbow@amazon.com>
 <CAAQJX_SL0UHzLDzsN-vRn449Cwyu0fphfyYZyovjfcKmWLJDKg@mail.gmail.com>
 <C7CE7EEF248E2B48BBA63D0ABEEE700C45DF9E3F02@GUREXMB01.ASIAN.AD.ARICENT.COM>
 <CAAQJX_SAUYaNbXrsLaTTaBfR_Mtr5A4ZDwskDNMXEd3SsKx6fA@mail.gmail.com>
 <5278C412.4000204@6wind.com>
Date: Tue, 5 Nov 2013 15:59:11 +0400
Message-ID: <CAAQJX_Q9cOsKspauRMC9aJwAR+o3FhztxsiT4cdBtandJLsE9Q@mail.gmail.com>
From: Alexander Belyakov <abelyako@gmail.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: "dev@dpdk.org" <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
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 11:58:18 -0000

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