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 33B11A0351; Fri, 4 Mar 2022 10:58:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1785440150; Fri, 4 Mar 2022 10:58:24 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 37CE64013F for ; Fri, 4 Mar 2022 10:58:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646387902; x=1677923902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jBiKoIZNyFdDgW7R7YbTc8vn59C7IEAqzsXB6s5x0Rc=; b=YRvCK3qVxyBEEjmKUDV3W5+BdtQotJXdpC6P3lDAvz4TQgMYCTluUBge TTUvtAn0mlEJ6WDzAZ7rFMiuDR3hYry/QSdZdoauQ6LGLqZrnDEx5CCcZ 0/dVjBRtHbohfLWncRWBTJLM1laQT8+wZtRry3Obd0qgi23TJqRYxWdCT wUbY/mTwLwmsE/jwHkTO598aKMMVPuwMfdtkHYGyKGY9ZOjOKBtDBVAAx fCy9gYlOLUXP7SPamhbTX77FGyMcHuVdlvwKxPi/wtS1TeHURS6kB++yM NjDfZ/nAednKqoNW/uwDtTAjaOHy68mIQsW5Qm4+/sps5WpVlvSDdcX78 g==; X-IronPort-AV: E=McAfee;i="6200,9189,10275"; a="254135284" X-IronPort-AV: E=Sophos;i="5.90,154,1643702400"; d="scan'208";a="254135284" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 01:58:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,154,1643702400"; d="scan'208";a="594733699" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by fmsmga008.fm.intel.com with ESMTP; 04 Mar 2022 01:58:20 -0800 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) 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.21; Fri, 4 Mar 2022 01:58:18 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX605.ccr.corp.intel.com (10.109.6.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 4 Mar 2022 17:58:11 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.2308.021; Fri, 4 Mar 2022 17:58:11 +0800 From: "Zhang, Qi Z" To: Stephen Hemminger , "Ding, Xuan" CC: "thomas@monjalon.net" , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "viacheslavo@nvidia.com" , "Yu, Ping" , "Wang, YuanX" Subject: RE: [RFC] ethdev: introduce protocol type based header split Thread-Topic: [RFC] ethdev: introduce protocol type based header split Thread-Index: AQHYLsRaim7ezLmaXEqNPKPgSYjBOqytUDIAgAGouzA= Date: Fri, 4 Mar 2022 09:58:11 +0000 Message-ID: References: <20220303060136.36427-1-xuan.ding@intel.com> <20220303081539.1de139f9@hermes.local> In-Reply-To: <20220303081539.1de139f9@hermes.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 > -----Original Message----- > From: Stephen Hemminger > Sent: Friday, March 4, 2022 12:16 AM > To: Ding, Xuan > Cc: thomas@monjalon.net; Yigit, Ferruh ; > andrew.rybchenko@oktetlabs.ru; dev@dpdk.org; viacheslavo@nvidia.com; > Zhang, Qi Z ; Yu, Ping ; Wang, > YuanX > Subject: Re: [RFC] ethdev: introduce protocol type based header split >=20 > On Thu, 3 Mar 2022 06:01:36 +0000 > xuan.ding@intel.com wrote: >=20 > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index > > c2d1f9a972..6743648c22 100644 > > --- a/lib/ethdev/rte_ethdev.h > > +++ b/lib/ethdev/rte_ethdev.h > > @@ -1202,7 +1202,8 @@ struct rte_eth_rxseg_split { > > struct rte_mempool *mp; /**< Memory pool to allocate segment from. > */ > > uint16_t length; /**< Segment data length, configures split point. */ > > uint16_t offset; /**< Data offset from beginning of mbuf data buffer.= */ > > - uint32_t reserved; /**< Reserved field. */ > > + uint16_t proto; > > + uint16_t reserved; /**< Reserved field. */ > > }; >=20 > This feature suffers from a common bad design pattern. > You can't just start using reserved fields unless the previous versions e= nforced > that the field was a particular value (usually zero). Yes, agree, that's a mistake there is no document for the reserved field in= the previous release, and usually, it should be zero,=20 And I think one of the typical purposes of the reserved field is to make li= fe easy for new feature adding without breaking ABI. So, should we just take the risk as I guess it might not be a big deal in r= eal cases?=20 Thanks Qi >=20 > There is no guarantee that application will initialize these reserved fie= lds and > now using them risks breaking the API/ABI. It looks like >=20 > rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg, >=20 > Would have had to check in previous release. >=20 > This probably has to wait until 22.11 next API release.