From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0048.outbound.protection.outlook.com [104.47.1.48]) by dpdk.org (Postfix) with ESMTP id 6773C23D; Tue, 24 Apr 2018 15:41:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GijNmvWO3jtztTY3N0sGcoEIEyRV8PW95UOggxilyf8=; b=Yd96qxO4+rj+HE5zUevLbgrPAMgGG4V7JTTib/liukK+6j1YXnT9jJql/DqGLBJa5fv5k8wQRUNn9wc7sWw1XhIVHLSgLUe6otkpXwlnFwO0ALTpFAuYfbOYCu1HfMBl2EnrlHgiMDvBgVGqgNMpb4TWRU4rirPX9ZbwZwcREiI= Received: from HE1PR0501MB2314.eurprd05.prod.outlook.com (10.168.34.19) by HE1PR0501MB2521.eurprd05.prod.outlook.com (10.168.126.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.15; Tue, 24 Apr 2018 13:41:53 +0000 Received: from HE1PR0501MB2314.eurprd05.prod.outlook.com ([fe80::d405:aec8:cd2f:85cc]) by HE1PR0501MB2314.eurprd05.prod.outlook.com ([fe80::d405:aec8:cd2f:85cc%18]) with mapi id 15.20.0675.018; Tue, 24 Apr 2018 13:41:53 +0000 From: Ophir Munk To: "Ananyev, Konstantin" , "Hu, Jiayu" , "dev@dpdk.org" CC: Thomas Monjalon , Olga Shern , Pascal Mazon , "stable@dpdk.org" Thread-Topic: [PATCH v1] gso: fix marking TCP checksum flag in TCP segments Thread-Index: AQHT2kUpp26DE2UvPU2Ou46q1OX+56QNvmoAgAHdJECAACWbgIAABehwgAAUuICAAAk3sA== Date: Tue, 24 Apr 2018 13:41:53 +0000 Message-ID: References: <1524406859-29585-1-git-send-email-ophirmu@mellanox.com> <2601191342CEEE43887BDE71AB977258AEA5081C@IRSMSX102.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258AEA5221E@IRSMSX102.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258AEA5221E@IRSMSX102.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ophirmu@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0501MB2521; 7:+cTKwk/a/NexQ1Y4zrvwcX/m2toaguBGfhWoSsJ1L1QYzb2Y5z+nSZD0Lm1EeIt+IDz33SFgWbiH8rtCxtOaqP4rm3PGNmep72dJioqooXVBA3cw0d7qLeO6r2f0A0FZB/hEidNxBVWZ7MHoWi5CIr7xi3yVNSctDsXaWw4dalV18aK1ICZJ4fdzqg/B0V4V9qJFBMTJ0o708/tsf31Qqyt3bAsm6HxaInBNnnGvZtUpy7Tv663frONDQU+qoAOA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0501MB2521; x-ms-traffictypediagnostic: HE1PR0501MB2521: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(45079756050767)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231232)(944501410)(52105095)(6055026)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0501MB2521; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0501MB2521; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(39860400002)(376002)(366004)(396003)(13464003)(69234005)(199004)(189003)(9686003)(14454004)(4326008)(102836004)(478600001)(6436002)(11346002)(6506007)(2906002)(446003)(53546011)(5660300001)(229853002)(93886005)(59450400001)(186003)(26005)(33656002)(6116002)(106356001)(3280700002)(5250100002)(6246003)(2900100001)(8936002)(81166006)(8676002)(7736002)(2501003)(68736007)(81156014)(105586002)(3660700001)(66066001)(76176011)(7696005)(74316002)(486006)(476003)(99286004)(3846002)(97736004)(316002)(305945005)(966005)(110136005)(25786009)(55016002)(45080400002)(6306002)(54906003)(86362001)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2521; H:HE1PR0501MB2314.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bYbscswdeAdUVzYbccoke/+vDYe1CUH7So3LcRFCmsWm1HTMmDXmro3uYa9Ipe8Oa1pMDChiWujqBHfoMXuKzxbUZRiyyEqIuGsIabh/7vVwGc2TLE4vLUCMDRSYtuVfMvxe8sbDnleu0h1jOopBahxNnTQ6oAeUMtS0Nx/djwKECuiXhiXdwvxQ/NAc9LsK spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0212fab7-5779-42cc-6162-08d5a9e923d4 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0212fab7-5779-42cc-6162-08d5a9e923d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2018 13:41:53.4982 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2521 Subject: Re: [dpdk-stable] [PATCH v1] gso: fix marking TCP checksum flag in TCP segments X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 13:41:56 -0000 Hi Konstantin, > -----Original Message----- > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] > Sent: Tuesday, April 24, 2018 3:31 PM > To: Ophir Munk ; Hu, Jiayu ; > dev@dpdk.org > Cc: Thomas Monjalon ; Olga Shern > ; Pascal Mazon ; > stable@dpdk.org > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP segment= s >=20 >=20 > Hi Ophir, >=20 > > > > Hi Konstantin, > > Please see inline > > > > > -----Original Message----- > > > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] > > > Sent: Tuesday, April 24, 2018 1:56 PM > > > To: Ophir Munk ; Hu, Jiayu > > > ; dev@dpdk.org > > > Cc: Thomas Monjalon ; Olga Shern > > > ; Pascal Mazon ; > > > stable@dpdk.org > > > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP > > > segments > > > > > > > > > > > > > -----Original Message----- > > > > From: Ophir Munk [mailto:ophirmu@mellanox.com] > > > > Sent: Tuesday, April 24, 2018 10:44 AM > > > > To: Hu, Jiayu ; dev@dpdk.org; Ananyev, > > > > Konstantin > > > > Cc: Thomas Monjalon ; Olga Shern > > > > ; Pascal Mazon ; > > > > stable@dpdk.org > > > > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP > > > > segments > > > > > > > > Hi Jiayu, > > > > Please find comments inline > > > > > > > > > -----Original Message----- > > > > > From: Hu, Jiayu [mailto:jiayu.hu@intel.com] > > > > > Sent: Monday, April 23, 2018 7:14 AM > > > > > To: Ophir Munk ; dev@dpdk.org; Ananyev, > > > > > Konstantin > > > > > Cc: Thomas Monjalon ; Olga Shern > > > > > ; Pascal Mazon ; > > > > > stable@dpdk.org > > > > > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in > > > > > TCP segments > > > > > > > > > > Hi Ophir, > > > > > > > > > > In the GSO design, the GSO library doesn't care about checksums, > > > > > which means it doesn't check if input packets have correct > > > > > checksums, and it doesn't do any checksum related work for the > > > > > output GSO segments. It depends on the callers to use HW or SW > > > > > checksum calculation for output packets. This is why the GSO > > > > > library doesn't set PKT_TX_TCP_CKSUM. So I don't think it's a bug= . > > > > > > > > > > > > > Can you please reconsider this design? I think the GSO library > > > > should imitate the HW behavior where TCP segments checksum is > > > > automatically calculated without explicitly requesting it. I am > > > > not saying that GSO library > > > itself should calculate the checksums - but at least it should mark > > > each segment as requiring this calculation. > > > > > > But gso has no idea how this packet will be processed after it. > > > > GSO shouldn't know. It should only mark the fact that a new TCP segment > was created without a TCP checksum. > > >=20 > Ok, but new IP header was also created. And might be outer ip/udp (in cas= e > of tunnel). > If we go that way we'll have to set flags for each them. >=20 No. The application should set the PKT_TX_IP_CKSUM or other flags which wil= l be forwarded by TAP PMD to GSO library which will clone them in the new T= CP segments. The only concern is about PKT_TX_TCP_SEG versus PTK_TX_TCP_CKS= UM flags.=20 By dpdk design the PKT_TX_TCP_SEGS and PKT_TX_TCP_CKSUM flags are mutual ex= clusive. They do not co-exist, but they are replaceable. You can verify it = in testpmd implementation, other PMDs and code documentation (please note p= revious code snippets examples in this thread). > > > Caller can choose to calculate L3/L4 cksum in SW or might be going > > > to use HW offloads. > > > > Assuming TSO is configured then you suggest that TAP PMD will mark by > > itself the TCP_CKSUM flag for all packets returned from GSO library? >=20 > Yes. >=20 > > > > > In later case nothing stops the caller to update mbuf->ol_flags in a > > > way he likes (TCP_CKSUM, IP_CKSUM, etc.). > > > Konstantin > > > > > > > Please note that TCP_SEG flag is cleared by GSO library in 2 different = cases: > > 1. Packet length equals to or is bigger than GSO size. In this case new= TCP > segments are created with no TCP checksum. > > 2. Packet length is smaller than GSO size. In this case no TCP > > segmentation is required. The original packet is returned and its exist= ing > TCP checksum is OK. > > > > In the latter case TAP PMD will always calculate TCP checksum in SW > (performance concerns) where this could have been saved. > > I am thinking of a practical scenario where TSO is configured but all > > packets are smaller than GSO size, however TAP PMD unnecessarily > recalculates their checksums. > > > > How do you suggest to avoid this scenario? >=20 > Probably something like that: >=20 > rc =3D rte_gso_segment(pkt_in, gso_ctx, pkts_out, nb_pkts_out); if (rc = =3D=3D 1 && > pkt_in =3D=3D pkts_out[0] =3D=3D pkt_in) { > /* no gso was performed */ > } else { > /* new packets, update ol_flags if needed */ } >=20 > ? >=20 Regarding the check: "pkts_out[0] =3D=3D pkt_in " - I would prefer an "API= approach" rather than relying on internal code specifics. > Another possibility - might be make chages in librte_gso to allow user to > specify what flags to set for the output packets (probably via > rte_gso_ctx.flag) >=20 I will gladly review any new enhancement. However, for 18.05, can we please= accept this patch as a practical solution for now? > Konstantin >=20 > > > > > > > > In my opinion, it's not a good idea to enable HW TCP checksum > > > > > calculation silently, and without the aware of the caller. In > > > > > fact, the caller always know it does SW TSO (i.e. GSO), instead o= f real > HW TSO. > > > > > > > > This is not correct. Consider net_failsafe with 2 sub-devices: one > > > > is a HW PCI device, the other one is a SW TAP device. Failsafe > > > > must work > > > transparently with these two sub-devices and the caller cannot tell > > > if TSO is done in SW or HW. > > > > > > > > > If the caller wants HW > > > > > checksum calculation, it can add PKT_TX_TCP_CKSUM to ol_flags > > > > > before or after calling the GSO library. > > > > > > > > > > > > > FYI - TAP TSO patches were submitted to dpdk.org mailing list. > > > > These > > > patches use the GSO library. > > > > > > > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fd > > > pd > > > > > > > > k.org%2Fdev%2Fpatchwork%2Fpatch%2F38666%2F&data=3D02%7C01%7Coph > > > irmu%40me > > > > > > > > llanox.com%7C7455c8e31c7a4364bc7108d5a9d20008%7Ca652971c7d2e4d > > > 9ba6a4d1 > > > > > > > > 49256f461b%7C0%7C0%7C636601641779974217&sdata=3DCF7EvhXG%2BrH% > > > 2BPiQEbvM0 > > > > mC%2FSpqobneKaoV03j5VrSDw%3D&reserved=3D0 > > > > > > > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fd > > > pd > > > > > > > > k.org%2Fdev%2Fpatchwork%2Fpatch%2F38667%2F&data=3D02%7C01%7Coph > > > irmu%40me > > > > > > > > llanox.com%7C7455c8e31c7a4364bc7108d5a9d20008%7Ca652971c7d2e4d > > > 9ba6a4d1 > > > > > > > > 49256f461b%7C0%7C0%7C636601641779974217&sdata=3Dj9WVIj%2FKq6EN > > > WXu3mr5By1 > > > > toSowU8bqJRGZ19SxiGoI%3D&reserved=3D0 > > > > > > > > Running testpmd with TAP TSO is currently broken without the > > > > suggested > > > librte_gso patch. > > > > Please note testpmd implementation (app/test-pmd/csumonly.c > > > > b/app/test-pmd/csumonly.c) in case *both* TSO and TCP CKSUM are > > > > configured: > > > > > > > > if (tso_segsz) > > > > ol_flags |=3D PKT_TX_TCP_SEG; // *** if TSO is applicable = - the > packet > > > flags are only marked with PKT_TX_TCP_SEG and no > > > > PKT_TX_TCP_CKSUM *** > > > > else if (tx_offloads & DEV_TX_OFFLOAD_TCP_CKSUM) > > > > ol_flags |=3D PKT_TX_TCP_CKSUM; // *** PKT_TX_TCP_CKSUM = is > > > marked only if TSO is not applicable *** > > > > else { > > > > tcp_hdr->cksum =3D > > > > get_udptcp_checksum(l3_hdr, tcp_hdr, > > > > > > > > In other words - testpmd does not set TCP_CKSUM along with TCP_SEG > > > > therefore using testpmd with TAP/TSO will result in TCP segments > > > > with 0 > > > (incorrect) TCP checksums. > > > > > > > > In addition - please note the comments in > > > > lib/librte_mbuf/rte_mbuf.h which specify that PKT_TX_TCP_SEG flag > > > > implies the PKT_TX_TCP_CKSUM (hence it is not required to be > > > > explicitly set by the caller) > > > > > > > > /** > > > > * TCP segmentation offload. To enable this offload feature for a > > > > * packet to be transmitted on hardware supporting TSO: > > > > * - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag impli= es > > > > * PKT_TX_TCP_CKSUM) > > > > ... > > > > > > > > > Add Konstantin for more suggestions. > > > > > > > > > > Thanks, > > > > > Jiayu > > > > > > > > > > > -----Original Message----- > > > > > > From: Ophir Munk [mailto:ophirmu@mellanox.com] > > > > > > Sent: Sunday, April 22, 2018 10:21 PM > > > > > > To: dev@dpdk.org; Hu, Jiayu > > > > > > Cc: Thomas Monjalon ; Olga Shern > > > > > > ; Pascal Mazon > ; > > > > > Ophir > > > > > > Munk ; stable@dpdk.org > > > > > > Subject: [PATCH v1] gso: fix marking TCP checksum flag in TCP > > > > > > segments > > > > > > > > > > > > Large TCP packets which are marked with PKT_TX_TCP_SEG flag > > > > > > are segmented and the flag is cleared in the resulting > > > > > > segments, however, the segments checksum is not updated. It is > > > > > > therefore required to set the PKT_TX_TCP_CKSUM flag in each > > > > > > TCP segment in order to mark for the sending driver the need > > > > > > to update the TCP checksum before transmitting the segment. > > > > > > > > > > > > Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO") > > > > > > Cc: stable@dpdk.org > > > > > > > > > > > > Signed-off-by: Ophir Munk > > > > > > --- > > > > > > lib/librte_gso/rte_gso.c | 2 ++ > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > diff --git a/lib/librte_gso/rte_gso.c > > > > > > b/lib/librte_gso/rte_gso.c index a44e3d4..e9ce9ce 100644 > > > > > > --- a/lib/librte_gso/rte_gso.c > > > > > > +++ b/lib/librte_gso/rte_gso.c > > > > > > @@ -50,12 +50,14 @@ rte_gso_segment(struct rte_mbuf *pkt, > > > > > > ((IS_IPV4_GRE_TCP4(pkt->ol_flags) && > > > > > > (gso_ctx->gso_types & > > > > > > DEV_TX_OFFLOAD_GRE_TNL_TSO)))) { > > > > > > pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > > > > > > + pkt->ol_flags |=3D PKT_TX_TCP_CKSUM; > > > > > > ret =3D gso_tunnel_tcp4_segment(pkt, gso_size, > ipid_delta, > > > > > > direct_pool, indirect_pool, > > > > > > pkts_out, nb_pkts_out); > > > > > > } else if (IS_IPV4_TCP(pkt->ol_flags) && > > > > > > (gso_ctx->gso_types & > > > > > > DEV_TX_OFFLOAD_TCP_TSO)) { > > > > > > pkt->ol_flags &=3D (~PKT_TX_TCP_SEG); > > > > > > + pkt->ol_flags |=3D PKT_TX_TCP_CKSUM; > > > > > > ret =3D gso_tcp4_segment(pkt, gso_size, ipid_delta, > > > > > > direct_pool, indirect_pool, > > > > > > pkts_out, nb_pkts_out); > > > > > > -- > > > > > > 2.7.4