From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E0792A0093; Mon, 25 Apr 2022 17:05:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7782E41109; Mon, 25 Apr 2022 17:05:32 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id E207540E78 for ; Mon, 25 Apr 2022 17:05:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650899130; x=1682435130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NvBIkIiZSW4bT57iJw+l//ByRS2Di1HbUoplZFcWm+k=; b=HOO65fGwR8s9N7zY1kilxIIkV2uZ41vMgpvePBex2YQXCwy5oPSf7soG sd29abZEJOUL58LA9TkBbk9C+xbBZ5WtUbQG9YqMOgvYcz3WaHoffZVh9 tK7QOuHKSgvt4Sgv4gEUCj+lHrTsWoewgk6RfM1xpgi8xuPiIjT6jJCBD LfKWp66cQLWyyFffeoeB1rgwK9pqCf5r2uiqmTm6Nb78+ypoaYlnpBQv9 uHTiRr4fIMqnU0H1va81P3+kt883+Zl3/Q59bxNtsn2iMogrItFxqgzOy qs5HU75muyTra96mXe29ORT5ObtqYZ15rHtjLE3XWzeH8nPD4BGSWy0aM A==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="264120949" X-IronPort-AV: E=Sophos;i="5.90,288,1643702400"; d="scan'208";a="264120949" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 08:05:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,288,1643702400"; d="scan'208";a="628071464" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by fmsmga004.fm.intel.com with ESMTP; 25 Apr 2022 08:05:17 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Mon, 25 Apr 2022 08:05:16 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Mon, 25 Apr 2022 08:05:16 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Mon, 25 Apr 2022 08:05:16 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.176) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Mon, 25 Apr 2022 08:05:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mc/eZkH7U4qrHjd4ayb5zPXpfMRaN97cmA4T5ItspT6L8UEcEHtGkpCW46bUoG8IEoPihLACYIAtFB5OXre3YEVcsFWnLoFdAwJxJE3HnjvdmLiBiE4tU/OhN0dDOSu6BOlOvOOHDj98kKLcGcC3POPqvu2ubaDXSkXz9KQBZ8tuU5j5wopYLFk6UDYUn4WNslm+L9t1HaZRU/v9N5xG1CX29g7MW8ZLpC3Rb0TVyGXsKHai7RoqJBrNwcb6HTAkWmzpRmVGrFMeYp5vM/c0HL+jNBlv9Be3SYiVgh/BSDxLuMV7g7+IdNp5Tb+EjIfnXMbDce3rLtKnczUWoc+mPg== 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=q/SkmG57CpU+Y4TMGYDygLsWOjvfEJ69v/4w3+QtLAo=; b=G9kZMW2qHCWj81B6Cr/iafiuDb1hoyREM5lm0Z57Dm8GT3gAxS9oP09yGKu43fKHFtUsLZU4+NDFArQOZ8c+eKkejCAEm4D43fPx5/mhbprxXqsCSuNVr4zABC66YHGkoewEnnefHyxJbEuMqmZOhrRH0GfzR0bwcGpy3L7s7ArBKGslGF7U52xUYQnQpf16E3WuLKka3EioTCNqKnrOS842l4ATdeM9xYyolguBqcyjsWf2oX0FEQltC16+xZ5e9yaQoWVNJIBxx9XK8qG8ioyNjg1MwM/kJob59SeEK1OGLifczvMkvK2Kpw8qPIHU+OGiIMaWOKMPmA9VEwy9hA== 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 Received: from BN9PR11MB5513.namprd11.prod.outlook.com (2603:10b6:408:102::11) by BN9PR11MB5547.namprd11.prod.outlook.com (2603:10b6:408:104::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.14; Mon, 25 Apr 2022 15:05:14 +0000 Received: from BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::9147:90d3:4ea2:7838]) by BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::9147:90d3:4ea2:7838%6]) with mapi id 15.20.5186.021; Mon, 25 Apr 2022 15:05:14 +0000 From: "Ding, Xuan" To: Thomas Monjalon , Andrew Rybchenko , "Wu, WenxuanX" , "Li, Xiaoyun" , "Singh, Aman Deep" , "Zhang, Yuying" , "Zhang, Qi Z" , "dev@dpdk.org" CC: "dev@dpdk.org" , "stephen@networkplumber.org" , "mb@smartsharesystems.com" , "viacheslavo@nvidia.com" , "Yu, Ping" , "Wang, YuanX" , "david.marchand@redhat.com" , Ferruh Yigit Subject: RE: [v4 1/3] ethdev: introduce protocol type based header split Thread-Topic: [v4 1/3] ethdev: introduce protocol type based header split Thread-Index: AQHYRoFV1PgDPUFqJUelFXME57QWpKzkTNwAgAftbBCADg2lAIAGlLAQ Date: Mon, 25 Apr 2022 15:05:14 +0000 Message-ID: References: <20220303060136.36427-1-xuan.ding@intel.com> <253f6a27-0daa-d708-79e6-607228dda044@oktetlabs.ru> <3350018.QJadu78ljV@thomas> In-Reply-To: <3350018.QJadu78ljV@thomas> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.401.20 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5c18216-ab17-4f02-c605-08da26cd007a x-ms-traffictypediagnostic: BN9PR11MB5547:EE_ x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yg2krh8oP0saGpPXgVlO2EHGHLtdFvLMSpbv6LzbIOGhuL0pHOIdQolbRg5P5HXzo/RBjfna/IYwOtumJAjDOIKZEQLOaD9trAl3w6gbiUQ/fbsPcBNqMwM6kV1B0aSpUeTr65e1SoX4YTW7F9GOB5WdMRZrhyrMlypDFW1VsQVlbCEXlcM2T/1GcOXMN/2lfoTzDDfeBKlV4m8jdcylBrYvDlNuUytti/a7w5knP8iDSLpfR2ws6jiqSOr3sZj+6SEs3O9HwEcUA/DHvKur6OTOe09yvNT2zr0fU1zYWD7YAvX+lnZ9aAKv0i1j2MKYX1vAkDdElraKU/74jLaYJWHuoX50csEW1Lraw9DZr3S/ezRDMzOu0VM7LecW8pg8JOrmxPjGKazUULjOzZiXE7Ibx1f2DfOgXLj5zHH8jtb3gKOmvIDahyoQ4eRN2UfyFtMtYcih89roRond+F16YSeXTwqOt/cG6MZsAK8UT410gNRjv6Ag43+ZP01HVPrCh1wvCaSJ4YwVIMqFKDpMwGNisysXRA+s9o5XZafeSURNSiawQCcsUkQFx7FKCxbMtjmpF+HqrFDEiizYmmNszA6LlDUv1Jr+JJ/6Uieyv92GcpPcM+4BIL7S14ws5dCN4acPRwr5m2fqA7xFcekY4hPR3q3CslWPEH2jlklbvHbHAn6GCKipcA26q3+HiMoCh4ja264i/YULmdw7wq0wMMST9GSMu9ZBfxGxwX8Maag= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR11MB5513.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(9686003)(26005)(186003)(54906003)(110136005)(71200400001)(6506007)(7696005)(66556008)(4326008)(8936002)(55016003)(33656002)(508600001)(76116006)(66946007)(66446008)(64756008)(8676002)(53546011)(5660300002)(86362001)(66476007)(38070700005)(316002)(38100700002)(83380400001)(2906002)(122000001)(52536014)(921005)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NXFn9sCBKLAxeJ2L6uOAK8QS9YruVAvcXD5+ZahtaXWaoyQVwPft0/xZXNGa?= =?us-ascii?Q?ZE4+A3q8wIBnIyPpvfWh+nbdq74BXOHF+monx58BXNC/xpsxQO/6DtUQrTTK?= =?us-ascii?Q?+++T/OtsR94Peyem82O0rKV485HyinXsYMBTKYUu2HCYq4mwPDHtcOXrAHyR?= =?us-ascii?Q?ZqOnYAZpRuN82WtiH6LCFUh+n5odx9uPoNhSNaOsfHCVKoU+szoHG3aJCG6a?= =?us-ascii?Q?5gnTQbtX0X0kmK1P6VbQQN+ZsR1xInlRVUcSttLRy58X3zSS/lwuqhLKeK9t?= =?us-ascii?Q?eR4R7CPypSSexxID6DqaqZOSRe51eC0RvMZo3tctI6x9XZsWOYfYJyUyxWlx?= =?us-ascii?Q?HMyybAkTURtOSMf8yjcaqk3JljRRskDocO7NJy+q0NnoF/yvaCtt8qnkTF7h?= =?us-ascii?Q?HsvdfnU4tyzlM4/roX6lju7OHRLxOEM7n2OAE9XpadSrtHRQn47Vcg+0A1ae?= =?us-ascii?Q?OtzinyOrLIVAcBYaq3fmolZw5shQrls9bPQCb2KNAyhvECxpBIh4sodJk8Ne?= =?us-ascii?Q?t8GijJTTgghJWHdTeHRhq4qa610yp9uLhtU+gB9Huze+SdHxfP+YAdQiElvk?= =?us-ascii?Q?nZSocsi+SxGW68h8VVAG5iUxQDMEay01wTtPlNtTSeK7kSy5xEwEuNErMTnY?= =?us-ascii?Q?Lrpow4FHibaL4G2fIlm8MIj0h2zVjjvJk+uGYxFv8KNx7dQAZ7p4QalAJjuG?= =?us-ascii?Q?PvOH2wBpH9cZ1evEZ3swUPLPrsxEwswmrq+WsOpphXE9ludrReKTbDoiyyBR?= =?us-ascii?Q?jniHcnnZseqH/L+uPJn9tgInaRW4AxE8nY/fNmP+hUXsBeFPOQsBmE68LP5T?= =?us-ascii?Q?GfK3fDuOEBW95l87AW4c5wnWre9UZb3kXwHUsh7aIiq91VkvWHtx/xXrgIIH?= =?us-ascii?Q?Fn8MVndKk5xtVAvXna2r14GNxoc87srLRhqodAXpe4KE2pJ1zdfz+W7xRNlB?= =?us-ascii?Q?Rg+fJ4QoKNf87PtpcMlDlo3F5RGu36Eto59fffcbfo1k/fXhRQZKUkEHx8ML?= =?us-ascii?Q?phvPYRZKxQ9F1NR107ZX/Zwcd7U6OJMOg/M1gfTmbbUU2lxvZx/CFvqrQNlR?= =?us-ascii?Q?z+53MBQaCqa91m+QA22pdjiYBKsam3Zt0wnp+JemdQuQuOaQaWcoDwZ7KK/i?= =?us-ascii?Q?WI4Fa0J9QnAcoEKVzXqU7xT4PAOAJHP0QfskJrD7eRufu4XpjXxHC0sRnUbh?= =?us-ascii?Q?fSY/JxeWCUS4l7hJ7mwAhDmfsSOOra9IntT9s7/NaZTGKlLjHoPzWYVp5w6U?= =?us-ascii?Q?aMbKzJu0kLja8Tej0RJFMyWdrmk+38/mzL0gn6Iv20K+nM0tuDpyoLnjN+x7?= =?us-ascii?Q?TyvrzcBjsXnsMhegqUxhOWkJ9ksbFIOXxt29mAEyk9dsY+G6wjvLUv3laplF?= =?us-ascii?Q?LsuH1KrKvCx+KzDadUrTJHrfI/QKvWsFPMc79bayyOTpKcHNU4OMNDcshpHU?= =?us-ascii?Q?3Snj8zIX8ebMY6mcKSEyy+0j5kDlW6Ua2mDYQdkbm50PCc7dOtjltPdHs8RR?= =?us-ascii?Q?jEzL4Kp0eFm04eaLi1BOol5G3TznSZViozASssrZYF1Zl7myUyH2iAtUvPQz?= =?us-ascii?Q?vznqceDXUYGMjqeno6tO8C/j3igFyGbp2LO5W08VZLHQbUgENC0DBi6X0m6f?= =?us-ascii?Q?OZhUh4jm7Wh7OD6Lo5aluJU/i0eTIvZV2tuuWBEnoaS22QAtwNNoqJH6B9rs?= =?us-ascii?Q?L03B2sYobjXREvQe4+9QTU9j4Eut4pjlO6tlJ1SS9/cH72hyVlhCOcocbSrm?= =?us-ascii?Q?8RuxFuVnmA=3D=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: BN9PR11MB5513.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5c18216-ab17-4f02-c605-08da26cd007a X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2022 15:05:14.4075 (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: Vy5u+EORFxCMYV/q3ludEfRhshcMhyvDCDFpiP9uV6q3JzTkVXo13LOMrgrKPXp3fVhCGYdOw73tJ1uTxcoDcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5547 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Thomas, > -----Original Message----- > From: Thomas Monjalon > Sent: Thursday, April 21, 2022 6:28 PM > To: Andrew Rybchenko ; Wu, WenxuanX > ; Li, Xiaoyun ; Singh, > Aman Deep ; Zhang, Yuying > ; Zhang, Qi Z ; > dev@dpdk.org > Cc: dev@dpdk.org; stephen@networkplumber.org; > mb@smartsharesystems.com; viacheslavo@nvidia.com; Yu, Ping > ; Wang, YuanX ; > david.marchand@redhat.com; Ferruh Yigit ; Ding, Xuan > > Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split >=20 > 12/04/2022 18:15, Ding, Xuan: > > From: Andrew Rybchenko > > > On 4/2/22 13:41, wenxuanx.wu@intel.com wrote: > > > > From: Xuan Ding > > > > > > > > Header split consists of splitting a received packet into two > > > > separate regions based on the packet content. The split happens > > > > after the packet header and before the packet payload. Splitting > > > > is usually between the packet header that can be posted to a > > > > dedicated buffer and the packet payload that can be posted to a > different buffer. > > > > > > > > Currently, Rx buffer split supports length and offset based packet = split. > > > > Although header split is a subset of buffer split, configuring > > > > buffer split based on length is not suitable for NICs that do > > > > split based on header protocol types. Because tunneling makes the > > > > conversion from length to protocol type impossible. > > > > > > > > This patch extends the current buffer split to support protocol > > > > type and offset based header split. A new proto field is > > > > introduced in the rte_eth_rxseg_split structure reserved field to > > > > specify header protocol type. With Rx offload flag > > > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT enabled and protocol type > > > > configured, PMD will split the ingress packets into two separate > > > > regions. Currently, both inner and outer > > > > L2/L3/L4 level header split can be supported. > > > > > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT offload was introduced some > time ago > > > to substitute bit-field header_split in struct rte_eth_rxmode. It > > > allows to enable header split offload with the header size > > > controlled using split_hdr_size in the same structure. > > > > > > Right now I see no single PMD which actually supports > > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT with above definition. > > > Many examples and test apps initialize the field to 0 explicitly. > > > The most of drivers simply ignore split_hdr_size since the offload > > > is not advertised, but some double-check that its value is 0. > > > > > > I think that it means that the field should be removed on the next > > > LTS, and I'd say, together with the > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT offload bit. > > > > > > We should not redefine the offload meaning. > > > > Yes, you are right. No single PMD supports > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT now. > > Previously, I used this flag is to distinguish buffer split and header = split. > > The former supports multi-segments split by length and offset. > > The later supports two segments split by proto and offset. > > At this level, header split is a subset of buffer split. > > > > Since we shouldn't redefine the meaning of this offload, I will use > > the RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag. > > The existence of tunnel needs to define a proto field in buffer split, > > because some PMDs do not support split based on length and offset. >=20 > Before doing anything, the first patch of this series should make the cur= rent > status clearer. > Example, this line does not explain what it does: > uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/ > And header_split has been removed in ab3ce1e0c193 ("ethdev: remove old > offload API") >=20 > If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed, let's add a comment > to start a deprecation. Agree, I discussed with Andrew before that RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is no longer supported by any PMDs. I can send a separate patch of header split deprecation notice in 22.07, and start removing the code in 22.11. What do you think? >=20 > > > > For example, let's suppose we configured the Rx queue with the > > > > following segments: > > > > seg0 - pool0, off0=3D2B > > > > seg1 - pool1, off1=3D128B > > > > > > Corresponding feature is named Rx buffer split. > > > Does it mean that protocol type based header split requires Rx > > > buffer split feature to be supported? > > > > Protocol type based header split does not requires Rx buffer split. > > In previous design, the header split and buffer split are exclusive. > > Because we only configure one split offload for one RX queue. >=20 > Things must be made clear and documented. Thanks for your suggestion, the documents will be improved in v5. >=20 > > > > With header split type configured with > > > > RTE_ETH_RX_HEADER_SPLIT_UDP, the packet consists of > MAC_IP_UDP_PAYLOAD will be split like following: > > > > seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from > > > pool0 > > > > seg1 - payload @ 128 in mbuf from pool1 > > > > > > Is it always outermost UDP? Does it require both UDP over IPv4 and > > > UDP over > > > IPv6 to be supported? What will happen if only one is supported? How > > > application can find out which protocol stack are supported? > > > > Both inner and outer UDP are considered. > > Current design does not distinguish UDP over IPv4 or IPv6. > > If we want to support granularity like only IPv4 or IPv6 supported, > > user need add more configurations. > > > > If application want to find out which protocol stack is supported, one > > way I think is to expose the protocol stack supported by the driver thr= ough > dev_info. > > Any thoughts are welcomed :) > [...] > > > > + uint16_t reserved; /**< Reserved field. */ > > > > > > As far as I can see the structure is experimental. So, it should not > > > be the problem to extend it, but it is a really good question raised > > > by Stephen in RFC > > > v1 discussion. > > > Shouldn't we require that all reserved fields are initialized to > > > zero and ignored on processing? Frankly speaking I always thought > > > so, but failed to find the place were it is documented. > > > > Yes, it can be documented. By default is should be zero, and we can > > configure it to enable protocol type based buffer split. > > > > > @Thomas, @David, @Ferruh? >=20 > Yes that's very important to have a clear state of the reserved fields. > A value must be set and documented. Ditto, thanks for your comments. :) Regards, Xuan >=20 >=20