From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60077.outbound.protection.outlook.com [40.107.6.77]) by dpdk.org (Postfix) with ESMTP id 1CB52A48B for ; Mon, 22 Jan 2018 21:06:36 +0100 (CET) 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=cqYTJw9Hv/YCpq5gP5o4GW2gj5SSytnNQKRoPeEmclk=; b=qCqrtgU7AMhI/I2HcJCXecdvYYlR1rSxhD+UxcsrdzqOtvTWkJ2udcYOugMJCzcucYBJoAzazs0kQEhvwYe5+UfPJodtVEsNfTcpweiRJfCeWYe+T3bZgmQLiqhlPML6Mk5XYSKF14Ygbo4awfrZ2+PjgkoDx/hGFd28durZG5c= Received: from VI1PR05MB3149.eurprd05.prod.outlook.com (10.170.237.142) by VI1PR05MB1248.eurprd05.prod.outlook.com (10.162.16.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Mon, 22 Jan 2018 20:06:33 +0000 Received: from VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::789c:3f06:bb88:e29c]) by VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::789c:3f06:bb88:e29c%13]) with mapi id 15.20.0428.019; Mon, 22 Jan 2018 20:06:33 +0000 From: Shahaf Shuler To: Olivier Matz CC: "Xueming(Steven) Li" , Thomas Monjalon , Jingjing Wu , Yongseok Koh , "dev@dpdk.org" Thread-Topic: [PATCH 4/6] ethdev: introduce TX common tunnel offloads Thread-Index: AQHTiVqnmaKANdhRkEis33YKMNTlAKN2xwUAgAAFPYCAABZ1kIAJCKkAgAB3vrA= Date: Mon, 22 Jan 2018 20:06:32 +0000 Message-ID: References: <20180109141110.146250-1-xuemingl@mellanox.com> <20180109141110.146250-5-xuemingl@mellanox.com> <20180116171010.vt25o6uq3kb7cpzd@platinum> <20180122124638.pybfffk4iqjohouy@platinum> In-Reply-To: <20180122124638.pybfffk4iqjohouy@platinum> 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=shahafs@mellanox.com; x-originating-ip: [31.154.10.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR05MB1248; 6:TTJ+1YIcwvPvOWHJE6CoTcwc8LWVRVCBC7SjwtRNvkbvT7VulhfXVBhwOICl67Ir4ntQKtAqaaOdgjK1cPtqG+Csf1IAoC7KChyL1p4ORZqaRgD50U12sO9JaTeX7N/j5mFAomRxNaLIyyE2TaYT5CwXLBI6qJUX8hm56E2dv5rbi6ByUdf2DwncuAeyQVVBVnbm4gSGPw698aGjpkg7JynlGs3ktf6YMPEKswc6vSEjgNS1jn6MONHgZbNJwEV07ajsxBpM4sGgAV4v6B8SkN5L30gj2IgXRhCGL0/GiTUQ0+pVYfh7oynqEfm98dKuUxTQ2oA62tVZF/WpBeHFNPHW04EEETww+u/tcF0QJKrmdXRA1H6ZSnmIgNAZ+6YC; 5:VWthYhNz0J+dMvuUiMGw5JFLD73MJik8ZIruWkTvQg7FcQqh21WXppjZQUB/RKfKmeID0SmAplKraBKR7zjZK2F2eCz9Ej7pPGJBCa2eNwVCSww1UJb2JxnnXwVYU1Xk40MGqakiq4aMN9psVcqxh38x6v4CuIXWmZyYQDZ11ik=; 24:Xak3wWsfXtXDORfkoq+D5gUPpc43EDMTaDDuTxQAm7o1cbc1nXCHMFyCaKIMEoeVhpLJ4QGpN7DgIQmWgPc9PSy88rDAC6hULrDsxkX3ttM=; 7:ANlMQBhWJar3oCtgVUAVRDrmh52TSMMbd6Agec5jAmx0S4+eZFTy0aTEdIGic9QtXIw4gCmKe/1B3MiasRD0Wr+Ug8r6ah9e1c0267hoeAYHjJ1ZmNa+tD9ulU/EQlsNR4ZrunF2DoNOgfNQ1hNAgQVENXVVCp94fA1JiSiwuHDGtWR42nDgWos5Kgget9RO+QMSve10vWhV9oU96QJjcUESKk3UCR/DsgWEou2CaHBqFxa2wbLBaDGO0dn1bCWo x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: aec3f67a-93a3-44d9-7f72-08d561d3a241 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7153060)(7193020); SRVR:VI1PR05MB1248; x-ms-traffictypediagnostic: VI1PR05MB1248: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(2400081)(944501161)(6055026)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR05MB1248; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR05MB1248; x-forefront-prvs: 0560A2214D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(346002)(366004)(376002)(396003)(51444003)(199004)(189003)(305945005)(478600001)(5250100002)(8676002)(3280700002)(6436002)(3660700001)(81156014)(81166006)(2950100002)(106356001)(26005)(6916009)(6246003)(105586002)(2906002)(59450400001)(6116002)(76176011)(86362001)(6506007)(8936002)(102836004)(3846002)(68736007)(97736004)(25786009)(7696005)(99286004)(74316002)(54906003)(561944003)(229853002)(5660300001)(66066001)(53936002)(33656002)(4326008)(14454004)(93886005)(9686003)(7736002)(316002)(55016002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB1248; H:VI1PR05MB3149.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: D2dEVN+ODxNtBRxSWGAn55RRDl9pYhvYtIzl+nxNaWma2qm2WAudszwAeD3WUuBNHC6T2T+kUeLNerYZ0HAwZg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: aec3f67a-93a3-44d9-7f72-08d561d3a241 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 20:06:32.9894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB1248 Subject: Re: [dpdk-dev] [PATCH 4/6] ethdev: introduce TX common tunnel offloads X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 20:06:36 -0000 Monday, January 22, 2018 2:47 PM, Olivier Matz: > Hi, >=20 > On Tue, Jan 16, 2018 at 07:06:15PM +0000, Shahaf Shuler wrote: > > Hi Oliver, Xueming, > > > > Tuesday, January 16, 2018 7:29 PM, Xueming(Steven) Li: > > > > Hi Xueming, > > > > > > > > On Tue, Jan 09, 2018 at 10:11:08PM +0800, Xueming Li wrote: > > > > > */ > > > > > #define DEV_TX_OFFLOAD_SECURITY 0x00020000 > > > > > +/**< Device supports arbitrary tunnel chksum and tso offloading > > > > > +w/o > > > > knowing > > > > > + * tunnel detail. Checksum and TSO are calculated based on mbu= f > > > > fields: > > > > > + * l*_len, outer_l*_len > > > > > + * PKT_TX_OUTER_IPV6, PKT_TX_IPV6 > > > > > + * PKT_TX_IP_CKSUM, PKT_TX_TCP_CKSUM, > PKT_TX_UDP_CKSUM > > > > > + * When set application must guarantee correct header fields, = no > need > > > > to > > > > > + * specify tunnel type PKT_TX_TUNNEL_* for HW. > > > > > + */ > > > > I think some documentation is missing here. > > What the NIC needs to know to support the generic tunnel TSO and > checksum offloads is: > > 1. the length of each header > > 2. the type of the outer/inner l3/l4. Meaning is it IPv4/IPv6 and wheth= er it > is UDP/TCP. > > > > The outer IPv6 seems covered. The inner L4 seems missing. > > > > More details about this offload below. > > > > > > > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO > 0x00040000 > > > > > > > > > > struct rte_pci_device; > > > > > > > > > > > > > I'd like to have more details about this flag and its meaning. > > > > > > > > Let's say we want to do TSO on the following vxlan packet: > > > > Ether / IP1 / UDP / VXLAN / Ether / IP2 / TCP / Data > > > > > > > > With the current API, we need to pass the tunnel type to the > > > > hardware with the flag PKT_TX_TUNNEL_VXLAN. Thanks to that, the > > > > driver can forward this information to the hardware so it knows > > > > that the > > > > ip1->length, udp->length and optionally the udp->chksum have to be > > > > updated for each generated segment. > > > > > > > > With your proposal, if I understand properly, it is not expected > > > > to pass the tunnel type in the mbuf. So how can the hardware know > > > > if some fields have to be updated in the outer header? > > > > > > I'm not expert on hardware, the driver has to supply outer and inner > > > L3/L4 offsets, types and which field(s) to fill checksum, no length > > > update as far as I know. > > > > Mellanox HW is capable to parse the packet according to hints from the > driver. > > > > If you think about it, to calculate the IP checksum all you need to do = is know > the inner/outer IP offset, and the fact it is an IPv4. > > To calculate the inner TCP/UDP checksum it is the same. all that after = the L4 > is counted as payload and the pseudo header can be done with the > information about the IP. > > > > About TSO - just need to get the offset till the inner header so that t= he NIC > can append the full headers to every segment and update the inner/outer L= 3 > and L4 fields accordingly (which their location is known). >=20 > I think that's partially true. Let me try to clarify: >=20 > - in case of VXLAN (my previous example), the hw needs to update the > outer L3 (ip length) and L4 (udp length and optionnally checksum) > - in case of GRE, an update of the checksum is required if present. The > sequence number may also be increased (I don't know how widely it is > used). > - in case of a proprietary or unsupported tunnel, the hardware cannot > know which fields to update in the outer header. So I'm not sure > a "generic" flag is possible. >=20 > How can the application know which tunnels types are supported by the > hardware and which should be done in software? Yes I understand your point. maybe we should rephrase and change the name o= f the feature.=20 The support from the device is for inner and outer checksums on IPV4/TCP/UD= P and TSO for *any packet with the following format*: < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] / / [optional inner IPv4/IPv6] / [optional TCP/UDP] For example the following packets can use this feature: 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / GRE / MPLS / ipv4 / udp=20 >=20 >=20 > Olivier