From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50062.outbound.protection.outlook.com [40.107.5.62]) by dpdk.org (Postfix) with ESMTP id 9AC1111F5 for ; Wed, 21 Mar 2018 02:41:03 +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=xAZshZdkrjHfI6TYH6fXiDF0tBKH0UGH1J+UuDhCbAI=; b=KgrQH1YR9W5uoE4Cqfqstry7m/BIJ8rqcj1mPyn5o7J4aj+2b5/5kdLWRTBV5Ot9Gait2uylBcdz1xP95y9ahJn3wGIv+0IWQsYe9VkrLsKmfk39iWWdCDQXOmE+8zaHrV+wOZVXA+gKYndeaQ4FC1MKa1PgO7cndI0OLN7Iw2A= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by DB6PR0501MB2037.eurprd05.prod.outlook.com (2603:10a6:4:6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Wed, 21 Mar 2018 01:40:58 +0000 Date: Tue, 20 Mar 2018 18:40:48 -0700 From: Yongseok Koh To: Xueming Li Cc: Wenzhuo Lu , Jingjing Wu , Thomas Monjalon , Olivier MATZ , Shahaf Shuler , Ferruh Yigit , dev@dpdk.org Message-ID: <20180321014046.GA49883@yongseok-MBP.local> References: <20180109141110.146250-2-xuemingl@mellanox.com> <20180305145121.71866-2-xuemingl@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180305145121.71866-2-xuemingl@mellanox.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: BN6PR11CA0001.namprd11.prod.outlook.com (2603:10b6:405:2::11) To DB6PR0501MB2037.eurprd05.prod.outlook.com (2603:10a6:4:6::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b31adaa0-ae71-473f-8de2-08d58eccccfe X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(2017052603328)(7153060)(7193020); SRVR:DB6PR0501MB2037; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2037; 3:E2Oud1ODUrzCZ6mAVrnBZf7nHFgUbNGITsiSXmST0QEq3Xua+w85nDgaXd4imZfrcPpNPqBvpHjJfsU2Z5bWpAq9h+9D3Cq8u1HgwV+pY51BLwlH9Ba5IMnalHn3f8mL4EIu1+YJp5SxsDLTA6yLiyCAC5phFXm28e8eIyiqN41Drc9KPKfRt4j0hKAEQAHbxBRrRdyYue0QNyt3KK/Jwrrkn+pbAeMWxkDuv1XPjNFff811AB/mIeLMAh9SKDec; 25:KQ1KORC6EvRXZRWlUXM57DqUxFZq8FbY7aSOvJgXJQSqjRCTY11Taq3g02GDsTyZOySdym8fJyf2UuDnpUZne5gLpkH6ZOkeQQ8uozvumaXHO2C2Nw8ojAuVLEw863NCogAFeiV6iANAa3ppuCw0BG54t7Y847DnOV2PKiZSV8LZUAgANijKb+zTDLLIK5m7RvZNhYqTI5yAC8Zcfv03tGaZoqBSzw/W96t5DNe2y8uayyuy0nSZ2mcmi9GiX+aCvSZFpiaxn4AHg9jN7ci6shcrHD3lophBkKGWOg4qqVfr+GBt8Bgwhte849dIodEh2x0N8PgJ78nCziyjefRAMA==; 31:O3YN+pqulRuB/MZ4iU0won2dDoDRkE7jERCiHrMKQa62VP/bacrfKKQCGS8oGg7ty5A+TCzkWITZtxxpW6TtEVyzaDlHJmiilg/7JMvJajORb3nB4NEn1z9QYPWaHXOO7okuqtDdJ1w65K0EME+R6Mz448oU7px3VwGqDmrCF4MdmzxEei+M2uGPPQnbywFlQK3kEo4KuUM0RSfFUjRqk8WCToUrPKjPj89pnGjV9ts= X-MS-TrafficTypeDiagnostic: DB6PR0501MB2037: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2037; 20:syqmlcA/5NKtXGTfxkVKwT3eRg2nMg40qk/cQSxFKR3EDGXGjknsNSa7VCoLu1C1MvP/l/kkwGVsWmqAUbIdNqcmqUY0+nOTkrBy4VL6zmZYsfNZ17oFOx3JRVXlKUmNoyYEpygNsMGrx8xxoz9IP/PUZ9ELTeVf69HJvc9iOtCytv7apiWJKKzmvWdJsABxmf1bsndiRdQCjMxteTO2MuqZMHvB7SxbFkxhTgD2tbhEUEuE9+eEdI1mCQ4VUQ2CYBIpomWdjSFzaqITDavixfhPCLOoXwPRUFS1XsWdySo37Zum9hTkq9AoKF5GgWmfGWAHT1tISAI5P9Y6eMMZZZINW2OAUV16doDOkxTl+CiMYohFDH8yuEksHnw3/GYMPQKK/8juIWovOLyRzvYegiVngT8m4lk/bYwjbCo94MRX/ZqcW3Cmfj95I3c9Rr7TXmeDZZV1iyBJYurL34P2A3L1NHIPPOpgl+8CbH/QUCLRW8NlwZA8kSHK5chnYqw5; 4:KUQbtDNJDKqpYSn0Kw9MjQHHfyOBzpPzet+pvtDvx5bROI/MGXjW2ApmjEXW180OBiZy7suCahbi6OTBcrn0u5vOQyaj79rjxUKZGzXKhKbSkIvNWmAcSVM/STq8lyih/KijjUpTaAW1t0352Ankc+MEiL1oTEU+RNMX6hNAPZAIlaxntspKWbuZi3FerEim5t1PZtrIxXFDDz6h0F5zSq95Ow21W6y2DZPZ97hCNCoxo3yPyrsyLtR7UjzctSiU59QDQJ1q+93GTy/wey9hOw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501317)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DB6PR0501MB2037; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0501MB2037; X-Forefront-PRVS: 0618E4E7E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(376002)(346002)(39860400002)(366004)(199004)(189003)(8676002)(23726003)(66066001)(305945005)(26005)(47776003)(316002)(6116002)(3846002)(16586007)(386003)(6506007)(6862004)(52116002)(50466002)(7696005)(33896004)(16526019)(6636002)(1076002)(6666003)(58126008)(54906003)(76176011)(81156014)(81166006)(59450400001)(97736004)(7736002)(2950100002)(4326008)(68736007)(105586002)(55016002)(5660300001)(53936002)(86362001)(9686003)(6246003)(229853002)(478600001)(25786009)(2906002)(8936002)(106356001)(33656002)(98436002)(18370500001)(41533002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0501MB2037; H:yongseok-MBP.local; 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-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR0501MB2037; 23:eLDw6YxotW2yajqyB++v7bk9GUnKCcBYwQg3bFs?= =?us-ascii?Q?f0rWYAASrlQg14F/C2TIXvc6IGgzJftaX22pALQPlg2SVKwQgv4c4sNHmfLw?= =?us-ascii?Q?ZO5aVbW1Ivf8Z7GV9RExsrdEPolRCOdCIHApclO2Wr8bq5tZw/LjYHUf6CbI?= =?us-ascii?Q?ffqMTMuUXNzMfM8LCw4GDiHnqlYtzcWdgMeFL48htTn4aXUXV5V5Zsw5jznl?= =?us-ascii?Q?zdU06ygKFF/f8L1IoS99LK7CtQZedjF7lRFiNnxnhe5vIavMEeVwsFqEJHqO?= =?us-ascii?Q?gzPHBoOSpuEG1mYhl+DeBMLn6dpr46JkB9pFyPzsN/+dp7I04c1r8jgjCZR5?= =?us-ascii?Q?Sl9yQGq1gi9AZ6kNsO40zZkJnu7v5mKipDB7zgO22OSXi6WkGWb62nZ8jU7N?= =?us-ascii?Q?110BZa9jKHci2s5FEHCg9AWER8vlxBlwdzuA+/6YAWtTGQtbijSRvXBQP3bE?= =?us-ascii?Q?xp3MjiCqujBvOHWnTydlP5b5FNGOO+xBpBFmVsYY7X1JRk9TEP6lvgbeK/lI?= =?us-ascii?Q?8RGOzp7IJOO471gBoWLVXbmWJ1c57DYKAV15RLSVXd6LdJL+t8Ns7C2x9bjY?= =?us-ascii?Q?iZOdbSEVM2dyyUx68DK6rD2LE6/lDiK6sSUB7eQv+ZqGv7QaMM6jgSydjjkN?= =?us-ascii?Q?cKu26Xfr+x3onmL9cgkdfZ0KGYhadYmY/QJ7DVRoLk/VHrZFOtN/UuyEDC6G?= =?us-ascii?Q?bZe+RUL2w6zfY7RwbmVJxULRt2GxKEiWMsjj/GFTuUYXAN4cLPGhHFEPu+pu?= =?us-ascii?Q?Zn0MNFph3Fb8fFmb7t9wLy5si6TE7YLJXAgkhx/ZjtsSI5JioW9Herpwseii?= =?us-ascii?Q?2RKMBCsoDIP0bDSFaGKhpB8azSSyvM+dKsDMgaHIsP8hAIgnLwh/Ycfw3mcB?= =?us-ascii?Q?Rs6bm3xEQNXFY7GKYBmMr9jI6rindIpcxzIpY2rLeI4MAyg1hqf0/J9DXtoX?= =?us-ascii?Q?nzsG2Vp3IQJtnGYIl0HDrRPxeTKPx/1nugHwMHcU8MM0lK4SGA/aS8w1rjqX?= =?us-ascii?Q?EV3fggYfPIOnVgOba1Aw4Lew5Sejd/TrQIWCg0demonzcM6qRQX+NUFwKJqF?= =?us-ascii?Q?Qq2EClmtKz930erdebm7Nz8c+j8mzhA+GJmsA4vmY0pCIiVOdJKjbU34e1Lo?= =?us-ascii?Q?aE4TU3W2CIv5Z9j0I+LQFD+EW9qPTYpKQ9qFAmQx6HbQWeUlKM3yrVqTgs5f?= =?us-ascii?Q?aZbGf1M+VOS0xjELWmiVnrZqbEaajUWxDQt8vOjcA3Tv83DfqvhjdJ1v27oB?= =?us-ascii?Q?nPdz9ql1kure6CZhVRkTWlhI6hAgjPKSBcJrOyENvlNR14ttxzBA5vJsGd0q?= =?us-ascii?Q?FnS0vjafAsNSu9CX7s5Mx7k/WomrQGV82YybPIvjUmLB2?= X-Microsoft-Antispam-Message-Info: H+FFSj5KArKO0A5GcP/C1D7sCy9Jl9PiaWBFfDpBkZrnK6Vv4mcQBaQ6TzH9tEBX0Y0Ivxhag+UUDur/fqcbpwBS4U3UmVtPmLiwbWtGfiKtj+KEbaDY6mPHRvaM39ZUFhYfhPxW3Ban0vVrEIJstWUo7Ur5PVd7ZbQ/VmRjD9Pd3MkMvS7Z+CghtDDjUugJ X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2037; 6:NLv2P4IpE6PmXLlZLWL3/8nAUd4v2gEkafM7NCWGPbUm5fVegUZam6mxnLN13GO6liMOCOGc+ZxdDCkGuMy2500x1NhiNxqJGWeDOr8VhD5p2xsjMz6jCdjcVwK9JPpMYEGNHEQMX3aC8Mr7mSo6iGmHUFKXdcXuaiHPxzw/iswrugWOqLeMMbCGyw1rHBeEI1fRydL9kK6o1RBlJ3m1mRINyVCLYkqUFVp6j5BHl+LeZ1939uIH7msz1wedq5RfbdfMajVcJ1/D1/wodnuoRFf4hAE6cCd3HPspep27OAQkWaYxxJG1kZP7FyzPfG3l08xQcgtvYBVhWzyQzgM/xn4yb2QBAGEwiVgDfTFQVg8=; 5:Y3koBFQ8h4nYsYkm1/IUPo0MpRv7KqHiB3zMG+P6jn4nuyWib0rntUWvcDpul5H+CPUYcBdood5zU+4LGbK0bfymk+JpGMDRIBeS8RInjbdrOF9ABlSDASNVsYs9dMyHvtSEbMwaUBfqdygs/KbxFHM45MIEbFWlZrYVkIWi4uA=; 24:vnz0WKoJThsw3xPFjTTlftjpngCUSaYi5ZTyKzFV9OM/UWGIRrR4goX5ve47Tjq4OST83yEaB/1f23KVtVG7PtJyevNc7T0ZEI2vC73G1IE=; 7:k3TvbOChqJqL6yL4G7GOGymue97b+LT8iQFsCam3w2mu6ZX9qKqa/e6tpvpvpTSG4y3306fgYp+iBsAW6YugYJXbjeTVdpcmpvA2APdb87IKXSMI6RntE5NmY9+5UsQMz7Z+Fk919emQq9nJKKxlCTSRoPtG64iJD3oPRCA6L0Xqs82vGxJ8HoihD1oNotiOznJkEJEUGHrfZKFTKdM5ys/S7ZdEvNoPRQSOV6C4gp9VN/gmBtvJ/D5Ha9ZGbNwE SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2018 01:40:58.7905 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b31adaa0-ae71-473f-8de2-08d58eccccfe X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0501MB2037 Subject: Re: [dpdk-dev] [PATCH v3 1/7] ethdev: introduce Tx generic tunnel L3/L4 offload 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, 21 Mar 2018 01:41:03 -0000 On Mon, Mar 05, 2018 at 10:51:15PM +0800, Xueming Li wrote: > This patch introduce new TX offload flags for device that supports > tunnel agnostic L3/L4 checksum and TSO offload. > > The support from the device is for inner and outer checksums on > IPV4/TCP/UDP and TSO for *any packet with the following format*: > > < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] / headers> / [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 > > Signed-off-by: Xueming Li > --- > lib/librte_ether/rte_ethdev.h | 24 ++++++++++++++++++++++++ > lib/librte_mbuf/rte_mbuf.c | 5 +++++ > lib/librte_mbuf/rte_mbuf.h | 18 ++++++++++++++++-- > 3 files changed, 45 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > index 036153306..66d12d3e0 100644 > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -980,6 +980,30 @@ struct rte_eth_conf { > * the same mempool and has refcnt = 1. > */ > #define DEV_TX_OFFLOAD_SECURITY 0x00020000 > +/**< Generic tunnel L3/L4 checksum offload. To enable this offload feature > + * for a packet to be transmitted on hardware supporting generic tunnel L3/L4 > + * checksum offload: > + * - fill outer_l2_len and outer_l3_len in mbuf > + * - fill l2_len and l3_len in mbuf > + * - set the flags PKT_TX_TUNNEL_xxx (use PKT_TX_TUNNEL_UNKNOWN if undefined) > + * - set the flags PKT_TX_OUTER_IP_CKSUM > + * - set the flags PKT_TX_IP_CKSUM > + * - set the flags PKT_TX_TCP_CKSUM, PKT_TX_SCTP_CKSUM or PKT_TX_UDP_CKSUM > + */ > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM 0x00040000 It looks redundant to me. Isn't it same as having DEV_TX_OFFLOAD_*_CKSUM? According to the API document, when PKT_TX_*_CKSUM is set, all the necessary length fields should be filled in (e.g. mbuf->outer_l?_len and mbuf->l?_len). It doesn't need to specify any tunnel type for checksum. For example, in order to request checksum offload for an unknown tunnel type which is similar to VxLAN, what should app do? Even without defining this new offload flag, it is currently possible by setting (PKT_TX_OUTER_IP_CKSUM | PKT_TX_OUTER_IPV4 | PKT_TX_IP_CKSUM | PKT_TX_IPV4 | PKT_TX_UDP_CKSUM) along with various length fields. > +/**< Generic tunnel segmentation offload. To enable it, the user needs to: > + * - fill outer_l2_len and outer_l3_len in mbuf > + * - fill l2_len and l3_len in mbuf > + * - set the flags PKT_TX_TUNNEL_xxx (use PKT_TX_TUNNEL_UNKNOWN if undefined) > + * - set the flags PKT_TX_OUTER_IPV4 or PKT_TX_OUTER_IPV6 > + * - if it's UDP tunnel, set the flags PKT_TX_OUTER_UDP > + * - set the flags PKT_TX_IPV4 or PKT_TX_IPV6 > + * - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag implies > + * PKT_TX_OUTER_IP_CKSUM, PKT_TX_IP_CKSUM and PKT_TX_TCP_CKSUM) > + * Hardware that supports generic tunnel TSO offload only update outer/inner > + * L3/L4 fields, tunnel fields are not touched. > + */ > +#define DEV_TX_OFFLOAD_GENERIC_TNL_TSO 0x00080000 Practically, for the existing TSO offloads for tunneled packets, tunnel type (PKT_TX_TUNNEL_*) is needed for knowing if transport is UDP-based or IP-based because the length field of UDP header should be updated for TSO. AFAIK, there's no TCP-based tunnel. For PKT_TX_TUNNEL_UNKNOWN, the only thing _unknown_ seems to be the type of transport and by defining PKT_TX_OUTER_UDP, you seem to recognize the type of transport between UDP and IP (it's not non-UDP). Given that, the new flags still look redundant and ambiguous. If PKT_TX_TUNNEL_VXLAN is set, there's no need to set PKT_TX_OUTER_UDP redundantly. Instead, I think defining PKT_TX_TUNNEL_UDP_UNKNOWN and PKT_TX_TUNNEL_IP_UNKNOWN could be a good alternative. It is only my humble two cents and I'd like to hear from more people regarding this. Thanks, Yongseok