From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id DB19CA0C4B
for <public@inbox.dpdk.org>; Tue, 19 Oct 2021 03:54:13 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id CCC02410E9;
Tue, 19 Oct 2021 03:54:13 +0200 (CEST)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
by mails.dpdk.org (Postfix) with ESMTP id 7392B4003E;
Tue, 19 Oct 2021 03:54:10 +0200 (CEST)
X-IronPort-AV: E=McAfee;i="6200,9189,10141"; a="228353676"
X-IronPort-AV: E=Sophos;i="5.85,383,1624345200"; d="scan'208";a="228353676"
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
18 Oct 2021 18:54:09 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.85,383,1624345200"; d="scan'208";a="566728700"
Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82])
by FMSMGA003.fm.intel.com with ESMTP; 18 Oct 2021 18:54:05 -0700
Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by
fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2242.12; Mon, 18 Oct 2021 18:54:04 -0700
Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by
fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2242.12; Mon, 18 Oct 2021 18:54:04 -0700
Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by
fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2242.12 via Frontend Transport; Mon, 18 Oct 2021 18:54:04 -0700
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.107)
by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.1.2242.12; Mon, 18 Oct 2021 18:54:04 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=IunrQlNFJYHdK6ATwpI3kOSIl2ZNKOQrCwaB3ej0VxBIF1HvWrrSouCcWuvVkkxjiq0U/BEB+Ui9PUMgkpwwrQOYpQ51HaHf3ZvXZVyu5kEGuqH7XIpkyFn4bRihpQscyT+ePmyZvcO8qNWXwBX2tYid2VRZ43aEwup6aLcdzg25TdZ38Sz3+Obf3gm6fB8eTj28o4CpCUvuXqCrO5PtI0iUWh43h/JpmJ/8fMhr5jNWYDVjhcmwRUrz1j0ypxbU5X7BISv4s50NrKHVOjfcqMJJlukgGGojYHO0c66DrFfXikd2OY9Jqiruyw9Tv0K7qCUkI/PRgGW9C7lUNvp/og==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=XrYQtICdWjLIlTKgWYzOgnJLbOZqlsDwqqLVG7cCxic=;
b=Erpx1wsWukcDdkiiuQ0rQnIG/zZEoYSjjZY+8LhM0s1wn9/KNFvEEhly1oexp36rQ6Afmh6dm+O1p0uMH3N4EejcM5Btn3bO/cyco5v6WnQiifuGDYrv5YtuD7JC6qkx4OwZYJ7YipCNkkPNA07++J4HgHwnDiLdC4oD4O1+1k5t2peqECQAK2mNiz+fn3ItGetAksp+w1TE1p9z2EYXWqIMHne3864XqQKNqa4Gd5KxACIeCRVG9CqzhzWpylIAO+1nL4/Pe0OChX4lQKpcxZHyANvc/m9wcpqSJ13tcMAuLVNfxkROHQLNqbWZTZ3B3gb1/CS7qT9ZFxKVvXOdTg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
dkim=pass header.d=intel.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;
s=selector2-intel-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=XrYQtICdWjLIlTKgWYzOgnJLbOZqlsDwqqLVG7cCxic=;
b=cVP8ETDtKfKDHOKcW7/w1qVlaxBBwIax7/FjZGrCBrQAHQwXZVTpLwlXQYel77w7DRgw2X/BBUvU2hIIjL6AMtxvjKjyv3CpZiPaP+4L6TtPbKoNy5XkXOyywALDrEh4EJk8uUoB7CxOHvREJPs5gQXJOk6McfCacCMtI80jihY=
Received: from DM4PR11MB5534.namprd11.prod.outlook.com (2603:10b6:5:391::22)
by DM5PR11MB1898.namprd11.prod.outlook.com (2603:10b6:3:114::10) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Tue, 19 Oct
2021 01:54:03 +0000
Received: from DM4PR11MB5534.namprd11.prod.outlook.com
([fe80::3d9b:76d7:e274:bad3]) by DM4PR11MB5534.namprd11.prod.outlook.com
([fe80::3d9b:76d7:e274:bad3%4]) with mapi id 15.20.4608.018; Tue, 19 Oct 2021
01:54:03 +0000
From: "Li, Xiaoyun" <xiaoyun.li@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Stephen Hemminger
<stephen@networkplumber.org>
CC: "Yigit, Ferruh" <ferruh.yigit@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
"stable@dpdk.org" <stable@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH] app/testpmd: fix l4 sw csum over multi
segments
Thread-Index: AQHXwYVaz7SPKH1dmE+Jm4+VK6BXS6vYFXOAgAACF1CAAHehAIAA/1pA
Date: Tue, 19 Oct 2021 01:54:02 +0000
Message-ID: <DM4PR11MB5534A61CF9F9874C316F37C999BD9@DM4PR11MB5534.namprd11.prod.outlook.com>
References: <20211015051306.320328-1-xiaoyun.li@intel.com>
<20211017200003.2bfbcf8c@hermes.local>
<DM4PR11MB553473987BFEC306A61B87F499BC9@DM4PR11MB5534.namprd11.prod.outlook.com>
<DM6PR11MB4491C776B4CD6B8F6F3A5B4C9ABC9@DM6PR11MB4491.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB4491C776B4CD6B8F6F3A5B4C9ABC9@DM6PR11MB4491.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: intel.com; dkim=none (message not signed)
header.d=none;intel.com; dmarc=none action=none header.from=intel.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e705d33f-e6d5-4cb1-c0a3-08d992a353a8
x-ms-traffictypediagnostic: DM5PR11MB1898:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM5PR11MB18981AEFDCF3A8960A4F32BA99BD9@DM5PR11MB1898.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZTyStZdNOuwqfcR19N+Q7UGex9izcRrV33mzn+DFXoed+lS6Wv62QcygcGwBiP++CHHqp9lUaOsbuz2a/USX+H/EFRLkI0qRuFJO2ieNIuach/6aw0OqoGGhUTi6WifEa6ODhtTV8XQqVWcZaPR7ypm61RdpROveyNCp3tB8yxCvqQEDDMuo2qWyt2DYTbrgDJBHQ5PNevPUZs6roOTpgz00fBcksbcKEPOa622L/Ad+1FfXuGO4QjOl7TWhP+OoHHpdeKh5ogzf20NBD5BW5faxyP257JctUFFCHt9AinlzMb7jYtTZLh8l8yesRWiX5mg/15W3ZwlopsYr8rbLlSPsM3v6TsKTAf9dSRdUb9IpgYudwqvPAp4U1n37OdQ1Z88arywUuBP3GHORGY8lQxrIs9oVWMPHmyDeS/1cgQZiBd00n5IhfdiIwh2I9WwRJTHPmimlPkSP6JRJ8kJMPXu4yYfmXyMm15lbJqsnRGLKBwpWoUuPj1F430FAus8XhbEJNwNUCxEXxGonX7yU0GuEAYP2ryIp2RBRa8ufRPuY2eGsIlLPFD1/wlMa8dokkqy7PnBRRr3M3AZzqkEcS10OZSeBX8i8RAM2/U9IXIpvlDyRREz7yis+X1o4L4tm81mePAXv8RmlNHZsuaPNA+8P7+VTOR/1L7pjdfN4bs6KMuXIKXnueEFYYf7ymK0iUi0p9gZoCJyUCSPKfJxnEw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:DM4PR11MB5534.namprd11.prod.outlook.com; PTR:; CAT:NONE;
SFS:(366004)(8936002)(4326008)(71200400001)(8676002)(5660300002)(38100700002)(2906002)(66946007)(64756008)(122000001)(82960400001)(53546011)(86362001)(110136005)(54906003)(316002)(66476007)(26005)(508600001)(55016002)(66446008)(9686003)(38070700005)(7696005)(76116006)(83380400001)(66556008)(6506007)(52536014)(33656002)(186003);
DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2urunJWDEYL7/+4FzPh4fLwjt1tsViuxslhFg8ePxCJ35ae+MbHZUbwPL46o?=
=?us-ascii?Q?uobqXWaNZ/AvdSNmtK2AhCvW/xh1su6VOHzzkFB+h0vCaAFOmZNQdmefRRLx?=
=?us-ascii?Q?uyoIR6YUdIVsnXDw37K4lkN1w8ORItbqOgqHROHdkD/iz+rf98efdGS/AnoV?=
=?us-ascii?Q?FKALmebuHGAi/0xeizNx34czM30xAiGj49GlxNlftrMWNgV6Z7LRQhiIQAkc?=
=?us-ascii?Q?js3OuSqaEHVTLEAMcGnDmFueNaVjNOYFPIQbdeIIChlq0uVYwnuLzvQYJleD?=
=?us-ascii?Q?wypBrDyPUsU1vRDDM3UZSQQlz4Eo0zZ0j2/CjbNXpDRsa/8279eNr8X4DgpC?=
=?us-ascii?Q?nahbXwgusvAGEgAvbNDVmQuT31QDX/kddohW405RBGnNhUwnqWJjDTy0hLae?=
=?us-ascii?Q?Y/uRTqg9EnlGQ6vsYEDtClwJnOZhN5LjtxH9t2RGopB2Pe7ylTtnFQ4msK6w?=
=?us-ascii?Q?wOEIYzP7bMDkZ++PNdfrian5eWUswiy23DHs0NadV12iAN7+12bpFhXouvsJ?=
=?us-ascii?Q?M+hv2iBncYfEB/3GJ4d3BuOLzd/JzS2aV9ShStLSWBO2jv2YPg8/smASZxbR?=
=?us-ascii?Q?/0r0jZW2lV/MSa5LF7gmmb5DS1jhZLkXPrMeq79XmfII8Kg1PyD/5oEglK+5?=
=?us-ascii?Q?fhuMlevmP4dvwkyrn/e6UlVidoXUVDup+CYdI9MNJIaAylms7Ck/E+74EDEr?=
=?us-ascii?Q?esMt9jRMVTQ6mzDklR9KZqt6SIAkeeXyQQApxnvdpeox5LdjvJ1R1VhkZSGl?=
=?us-ascii?Q?n5qJuB/u13uMEntSYpxrTJwW9K39AYNmeQkA0xcvQqOvddoy8mTYfQbMpUSf?=
=?us-ascii?Q?8e8+8RFT5fM7HXZpL05EHnmev35V+z+WNHplyPLuBi9UrbDzoGmDY9G83tbf?=
=?us-ascii?Q?umxKzArPTN4HhWYmu9F9YswP3UasiyMxJ2yxF1d3a5dsXVwa06HTGpiK02FL?=
=?us-ascii?Q?5OmEzA02+GXO6grTPxYlR2+eOoZFfqEb8MSGBFvaAGWfLk9Y18s7ET4Yh8tU?=
=?us-ascii?Q?SunuWjrY3u53CWpKuhvujQsj8FB41cbDZD+9RRgTEb6EdCH6Aq2NPKKYra7G?=
=?us-ascii?Q?SxzJIN0ssIe4FXgyWpXhgPaP50Ysc8TNSbHLr7gVcx2dXiaGvj0sB49GGLjS?=
=?us-ascii?Q?nf6JCak4/v7cGtpnScfOgTSQDxqM+EHo34GCESxXehlCVxKWzkj3z7Kt7Hut?=
=?us-ascii?Q?VQMfrD7x6Oknh9aCzKYfVXMS7u7QOuSZrbfTuwzJgJzO1R8QYEh/XArLezb2?=
=?us-ascii?Q?T38mHltkZKay0otemTJXzdNAelgJxQnMbqKPCNsjzMoFkSe2I2ka8TW6KSgh?=
=?us-ascii?Q?n20=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5534.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e705d33f-e6d5-4cb1-c0a3-08d992a353a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2021 01:54:02.9991 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: n0TLMpmdt4p6Ny3GBY46RU045aNuZhp4D9ruiSW5/IQvuWHWUm6Rs2RdqmSZvjCyid559KwA2Sq/TKqfphon0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1898
X-OriginatorOrg: intel.com
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/testpmd: fix l4 sw csum
over multi segments
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Monday, October 18, 2021 18:16
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Stephen Hemminger
> <stephen@networkplumber.org>
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org; stable@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] app/testpmd: fix l4 sw csum over multi
> segments
>=20
>=20
> > > > + /* When sw csum is needed, multi-segs needs a buf to contain
> > > > + * the whole packet for later UDP/TCP csum calculation.
> > > > + */
> > > > + if (m->nb_segs > 1 && !(tx_ol_flags & PKT_TX_TCP_SEG) &&
> > > > + !(tx_offloads & UDP_TCP_CSUM)) {
> > > > + l3_buf =3D rte_zmalloc("csum l3_buf",
> > > > + info.pkt_len - info.l2_len,
> > > > + RTE_CACHE_LINE_SIZE);
> > > > + rte_pktmbuf_read(m, info.l2_len,
> > > > + info.pkt_len - info.l2_len, l3_buf);
> > > > + l3_hdr =3D l3_buf;
> > > > + } else
> > > > + l3_hdr =3D (char *)eth_hdr + info.l2_len;
> > > >
> > >
> > > Rather than copying whole packet, make the code handle checksum
> streaming.
> >
> > Copying is the easiest way to do this.
> >
> > The problem of handling checksum streaming is that in the first
> > segment, l2 and l3 hdr len is 14 bytes when checksum takes 4 bytes each=
time.
> > If the datalen of the first segment is 4 bytes aligned (usual case),
> > for the second segment and the following segments, they may need to add=
a
> special 2 bytes 0x0 at the start.
>=20
> Didn't understand that one...
> Why you suddenly need to pad non-first segments with zeroes?
> Why simply rte_raw_cksum() can't be used for multi-seg case?
Normal udp/tcp packets:
The first segment: eth hdr + ip hdr + udp/tcp packet (The total length of t=
his is mbuf data len so like 2048, 4 bytes aligned)
The second segment: continue udp/tcp packet
Now, udp/tcp checksum is calculated. It will take the whole udp/tcp packet.=
4 bytes + 4 bytes + 4 bytes...
Then
1st segment: udp/tcp packet (size =3D 2048 - 14 =3D 2034, not 4 bytes align=
ed, 2 bytes left, if use rte_raw_cksum(), the last 2 bytes will be combined=
with 2 bytes zeros)
2nd segment: continue udp/tcp packet (size =3D data_len)
For 2nd segment, if don't add 2 bytes zeros first, the checksum value will =
be wrong.
Because it should be for example 0x1234 (0x12 is left in 1st, 0x34 is in 2n=
d), 0x1200+0x0034 is correct but 0x1200+0x3400 is not correct.
That's why I think all of the following segments needs zero padding first.
And above is only the usual case of normal tcp/udp packets. The issue also =
exists for tunnel packets which will calculate outer udp and inner udp/tcp =
checksum.
>=20
> > Also, mbuf is not passed down to process_inner/outer_chksum so the chan=
ge
> will be a lot.
>=20
> I also think that copying whole packet just to calculate a checksum - way=
too
> much overhead.
Yes. I agree. But it only happens when users don't enable checksum offload,=
don't enable TSO and the packet crosses multi-segments.