From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20054.outbound.protection.outlook.com [40.107.2.54]) by dpdk.org (Postfix) with ESMTP id A13FE1B296 for ; Wed, 17 Jan 2018 01:50:48 +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=8061duTkIUE1Q+S/X3eDRmaCfmQz1c8caqw7Dn9EITU=; b=SeIgLkuCTOOabcRXr3pp/KNfrBlJkXNAD6peLFe8z2NfKzuA5kRiQqgHU2hizU5Xr2PUFtj7ER0cTbTTQFDPj70acyWXvYgm1lABbm9bHnNUAEHaVViOCOx/Tg+iGJE5RYWzY9XzJwpCMSvPmYrMjNnLHPuWUz18zXFwQiMlNfA= Received: from VI1PR0501MB2045.eurprd05.prod.outlook.com (10.167.195.147) by VI1PR0501MB2591.eurprd05.prod.outlook.com (10.168.137.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Wed, 17 Jan 2018 00:50:47 +0000 Received: from VI1PR0501MB2045.eurprd05.prod.outlook.com ([fe80::2d4b:9768:b21a:e7e9]) by VI1PR0501MB2045.eurprd05.prod.outlook.com ([fe80::2d4b:9768:b21a:e7e9%14]) with mapi id 15.20.0407.012; Wed, 17 Jan 2018 00:50:47 +0000 From: Yongseok Koh To: "Xueming(Steven) Li" CC: Olivier MATZ , Thomas Monjalon , Jingjing Wu , Shahaf Shuler , "dev@dpdk.org" Thread-Topic: [PATCH 4/6] ethdev: introduce TX common tunnel offloads Thread-Index: AQHTiVqd4vS5Bwa+VkOJPljIVNgjL6N3R7SA Date: Wed, 17 Jan 2018 00:50:47 +0000 Message-ID: References: <20180109141110.146250-1-xuemingl@mellanox.com> <20180109141110.146250-5-xuemingl@mellanox.com> In-Reply-To: <20180109141110.146250-5-xuemingl@mellanox.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=yskoh@mellanox.com; x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0501MB2591; 7:c8mQbhwQUB59VJY+yvfriNauJouFNTVE9S+hQKrDGxCNBUhUIkiLBusRtNAeHrj1F0hcREfWkk5JwfWybX1Xr6yKJd3+IDqe7hQCacaFmioZBBrAyuR54NTsHVb8IH3TD8lKUNsE2tX2gFbEQfPmC9lhI8cnkdFjvPF8CM5e4dovTOfqr9X8uV1h/2p+ufw1CLBNzVqv+GKdqQg+flqy4RehP9oAxg9VENKcnmI2e0j4zS7qIAk3s7CnzAydIxRN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b41f99a0-b947-466c-113d-08d55d4458e9 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:VI1PR0501MB2591; x-ms-traffictypediagnostic: VI1PR0501MB2591: 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:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3231023)(944501161)(3002001)(93006095)(93001095)(6055026)(6041268)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0501MB2591; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR0501MB2591; x-forefront-prvs: 0555EC8317 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(366004)(346002)(376002)(39860400002)(199004)(189003)(24454002)(82746002)(305945005)(3846002)(7736002)(106356001)(6116002)(105586002)(5250100002)(478600001)(6862004)(5660300001)(33656002)(68736007)(99286004)(6246003)(2906002)(3660700001)(97736004)(3280700002)(66066001)(6512007)(81166006)(2950100002)(6636002)(81156014)(76176011)(8676002)(53936002)(25786009)(26005)(59450400001)(229853002)(37006003)(6436002)(2900100001)(54906003)(53546011)(6506007)(316002)(6486002)(14454004)(36756003)(102836004)(83716003)(8936002)(4326008)(575784001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2591; H:VI1PR0501MB2045.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: AwX1OiVKsFBbBw3Kzlu+LN0LeV7OARw4h8Xpo3/8ZPDlUEPC2C4LIUZnJtzY74JCCkCOzs5o5s0ng6qdSG9mZA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: b41f99a0-b947-466c-113d-08d55d4458e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 00:50:47.2996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2591 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: Wed, 17 Jan 2018 00:50:48 -0000 > On Jan 9, 2018, at 6:11 AM, Xueming Li wrote: >=20 > This patch introduce new DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO flag for > devices that support tunnel agnostic TX checksum and tso offloading. >=20 > Checksum offset and TSO header length are calculated based on mbuf > inner length l*_len, outer_l*_len and tx offload flags PKT_TX_*, tunnel > header length is part of inner l2_len, so device HW do cheksum and TSO > calculation w/o knowledge of perticular tunnel type. >=20 > When set application must guarantee that correct header types and > lengths for each inner and outer headers in mbuf header, no need to > specify tunnel type. >=20 > Signed-off-by: Xueming Li > --- > lib/librte_ether/rte_ethdev.h | 9 +++++++++ > 1 file changed, 9 insertions(+) >=20 > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.= h > index 57b61ed41..8457d01be 100644 > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -1003,6 +1003,15 @@ struct rte_eth_conf { > * the same mempool and has refcnt =3D 1. > */ > #define DEV_TX_OFFLOAD_SECURITY 0x00020000 > +/**< Device supports arbitrary tunnel chksum and tso offloading w/o know= ing > + * tunnel detail. Checksum and TSO are calculated based on mbuf 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. > + */ > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO 0x00040000 >=20 > struct rte_pci_device; I'm wondering why generic tunnel offload has to support checksum and TSO together. Those two are orthogonal, aren't they? App can request HW checksu= m offload even for non-TSO packets. Does DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO= mean HW can support checksum and TSO for generic tunnel? Then shouldn't it be tw= o flags instead? E.g. DEV_TX_OFFLOAD_GENERIC_TNL_TSO DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM Thanks Yongseok