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 0A4D1A00C2; Thu, 6 Oct 2022 17:14:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F2E0E42CB8; Thu, 6 Oct 2022 17:14:46 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id EA14442CB9 for ; Thu, 6 Oct 2022 17:14:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665069285; x=1696605285; h=from:to:cc:subject:date:message-id:mime-version; bh=XbD5cYYNcwb+XZXZwmm/5jmxEO0Ye+D73ZBBDzgyWr8=; b=SKeSn4gkCYSJeCiyji76XkVIx1y7NGCO6LyxE1Q0M1OF39YUt1L8KR+f yINEgHOL8hQZ8NcWC5N5OzAkA71DzLkSvoCHSERLiXojgncYX6C/IcHYK jDek45eLy7VySHnnB17tleel4U5P4M9vJHuPaqgYXXNO3a9bdnsznqgZ9 HWCH1JnzFpT/f0upCDN6qBlNTQToBal8wX2c13wwPpRipugHuaUNwR+2S xpoZ8/yyqY5ddUpGycrsekBV0lUaE4Z1JS+coTCScCre59vKjNZSmwfYK g8MI/6b2bpIg8IaaQy+euLEvJzDVS8E/SPs2nRjujzCN/b4sbU0CcCC+J A==; X-IronPort-AV: E=McAfee;i="6500,9779,10491"; a="303448862" X-IronPort-AV: E=Sophos;i="5.95,164,1661842800"; d="scan'208,217";a="303448862" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2022 08:14:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10491"; a="687467570" X-IronPort-AV: E=Sophos;i="5.95,164,1661842800"; d="scan'208,217";a="687467570" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga008.fm.intel.com with ESMTP; 06 Oct 2022 08:14:41 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 6 Oct 2022 08:14:41 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) 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.2375.31 via Frontend Transport; Thu, 6 Oct 2022 08:14:41 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Thu, 6 Oct 2022 08:14:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YJU8MmrkxWvW0r3hMt9pK7e8IpW9CAzfapTQkfXytd99NR3bPKoJfIY1hS4IRbJuCdx7GHHcGDOSuCm0N5gqTSm36uEoFGzLAubD/ix8tpC6F95S7veq/frqSZflYkRFli+EQ75sseNuDQ9Kmnekrk33nqSheiyXnFpp+Bn3uKlwmj0sc4Amw42G201ch3vjaTI24DIg390s4KiBwywD+HBZJCVgDMl0NXKjL1CxDDHjCF10qM1ixXFVeMhKqAosGmsd+dCkgBpXOofCewZIHVnxad1JT4vYd6FZFpbWffhC04IVyHdL415YxDLQLvbB6054YhJ0bBhRl6o4vwdlpw== 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=mATc2Yc9Ls0NZQ3rQRFDCh/h3SIItLsDkzoC4j5ufpg=; b=f1G0DREsYJLLkUW+NBYMLvHRHfF5pWe/SMZQLLRpuNKz0bS7JDU6PdFxfmLCqKNvbpC+YormWFxdfjcaLoyrRycyblTBjNr86tq3Gcnuzw7BUIfAvyJK1M0c3oCP6HTnhWtpjM364Mo9Bl4WpEZYdEQtQLvs726GvZ9PmQO4XbIu2BRLIL2FbCKNN3CppyZivnIQ9jxKCaA02CECAE4ojrmARdDC/LEmElcF9a4LvPR+s24kNjn04VLoZ7jGXHLhd12nfhNVO7h/wEMAMNuHGNTv6bgOErRK8y3rbgVs1BUjCR53yM7fTX1tRnTbHTBBmLxuxh58dycs52fvpI/Aiw== 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 DM6PR11MB3227.namprd11.prod.outlook.com (2603:10b6:5:5d::16) by PH7PR11MB6836.namprd11.prod.outlook.com (2603:10b6:510:1ef::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.24; Thu, 6 Oct 2022 15:14:38 +0000 Received: from DM6PR11MB3227.namprd11.prod.outlook.com ([fe80::d09b:81c7:d4b2:17b3]) by DM6PR11MB3227.namprd11.prod.outlook.com ([fe80::d09b:81c7:d4b2:17b3%7]) with mapi id 15.20.5676.030; Thu, 6 Oct 2022 15:14:38 +0000 From: "Mcnamara, John" To: "dev@dpdk.org" CC: "thomas@monjalon.net" , "david.marchand@redhat.com" , "orika@nvidia.com" Subject: DPDK Deprecation Notice Review Meeting 2022-09-30 Thread-Topic: DPDK Deprecation Notice Review Meeting 2022-09-30 Thread-Index: AdjZldaWAN3f/ou8Sz+sOrL4Wk+3wA== Date: Thu, 6 Oct 2022 15:14:38 +0000 Message-ID: Accept-Language: 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.500.17 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR11MB3227:EE_|PH7PR11MB6836:EE_ x-ms-office365-filtering-correlation-id: b4e9d4e3-0b31-4926-3d6c-08daa7ad7c5e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f0GnpB+j/u6jhx0N49PNf2Z//0oZHN3/Vaa4b5uoQQMgrb0EaWtjQf3xCGEiuM9RwEucODxILfMhmYsvJjUcLZjCM2tDQyacBR/oQehLA/PXy8zl92i6vKaCWCrdHGKs8OJIW+AFscfivNNxDZKL/KRn21kQq+r4w5iu0ZN9tZLR6jyAe8dyqqXLM9db76uk6mqFhVSQQOe0mjsBrbsqGSQGfqy0Ptuk0XZI4s9UFNWGGz76xDs59Bmv4Oy248oPRGkK6e6gSjslXZaiTgnoHo+JNR5h5EnbOn1silJyQfewqXmKR6fuV5As6BmximMOu2OVB78JqTh8Zqx7M9Jfj39w581WZAyp6UeFDCf4NTgG2gpLO6byIh/YtW8gaconiJb84vTJ1ycX984grgxY9MZBo0aj3AOAcoWVMUqdnnHxptsfISRzGLcD0TUH64RQQU38qsD/kD4PpnEbff401LugMeVeA4XjxRKogunt4DGiLcqguoNih9SfvX+8eoNPMIbi3G6vXPVu/tzZ0EXylJGOqZRwM8++Mhgz9rdseuqku+k1clN8oToD66GuqUMiNjRicRjXcQ/rtGvCG6sUydZS4MbOV4IPJMz/y4jrqAFd0KEanIn1ghgjUGHJFraQmGKesIURHqdnqVo/Y3+cVll0Zij08ikyBdfwWsxNIVmlLf1/bS75QyuRnvIIWlIYEx6Q/3LGDaksDQ50S71Thu0MtZIY32Pv+zc+90a0WDEBnMptGhbWMtkSQxl4QKf2iPo8MUZf+GRTra9gORKVXNCZ+QdHxxIzDLTVvwfYMWABZgEtGWG+7czLrtlmOyCtUEiLDkDCYYQn9vO3rOirxmHfapk5ubT3OekkbuK3/NQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3227.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(136003)(39860400002)(376002)(396003)(366004)(346002)(451199015)(4326008)(41300700001)(66446008)(122000001)(478600001)(8676002)(71200400001)(66476007)(2906002)(66556008)(66946007)(316002)(966005)(6916009)(166002)(38100700002)(83380400001)(86362001)(7696005)(33656002)(82960400001)(64756008)(54906003)(26005)(76116006)(9686003)(55016003)(38070700005)(6506007)(186003)(66899015)(5660300002)(30864003)(8936002)(52536014)(15650500001)(21314003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kPFm4ET/lph7jgZhUoeKcI1dBFv+TzPdZAWhXE90KxK+TDg8NC6X3TQw++S9?= =?us-ascii?Q?CgQEIyIqNHaX73426n2HBIVQrDjTZspaB9MJpa6BIOt2y70/ysLZg9Q8k37c?= =?us-ascii?Q?96+P8Ry/iwJTHczqHPtGMsu8Hy6dxZXlc+/N5+JaVqfS3RX8LEC9s10fKjwq?= =?us-ascii?Q?2ZG0+fhsMSP7VygtE1ull1QmTA+nbF98yXaqI/z0+NLuUkYECUdZNvjaepRL?= =?us-ascii?Q?oE1qyzzu3N/dJe6y1CgZHK/tsHR8wDEH7NeygUEwB8DW9uxDXhFWXCSgWABx?= =?us-ascii?Q?Rg9g89gJgVjk5Jn6Z9/SZN3T+gV4InS46FUPb2lkfyINweLF2hyKW4kB/PBI?= =?us-ascii?Q?+p/HLw/bBM38ib5Kb7oXJj0MTLyBOpxWctsOx2n6v6GZf68zcEmfE4wR4rnr?= =?us-ascii?Q?v6/fgzRGWZRS+Jje5iiuxsUGrVxPdWB7A8P4KoIw7gWm+aIL2XHms4BDoTa7?= =?us-ascii?Q?HOAldyxBPGKR92HAoJ/tVd5xihjwY4zrpOclZqUChPYY/LqH1RlEUogUmyOR?= =?us-ascii?Q?b7pipDICDqaf8vBz15QQky4HiumnqLE8IJYRbjt9GERKX9TzFpAiWSLeLRak?= =?us-ascii?Q?J+bjfxpmsBDqrjxNNGHojbCuLAMe1xHuxzox+XC9qK+bmBBe5/05guZKnW9+?= =?us-ascii?Q?ekYSJ1563YIcOvHwq0asvp9PuUAtQVnWBzNFlrgO7rhB9iVw/gz009VRRtUF?= =?us-ascii?Q?VAhAZr0M78fkInpRbSGks7PSS1cs6Qy77iAd07ED1iX9DVq6aCm3DoHyMboF?= =?us-ascii?Q?RI7KUG8MMK6k5rddFa4PNWso4qeMphWaGsXllU++CfJXOHLJ/cAeE1XMfuUi?= =?us-ascii?Q?Pig+6NXmIUgRPBfXVHPhgBXLk1erSNsgNHUZFmXY18hp5t3oHoyDxfuRTIfz?= =?us-ascii?Q?HBu9t1zqNLS3EMTuLFPB9AeJ16TwIwqtaJGyChAa3cuUnL9xKhVzbjFGdFiY?= =?us-ascii?Q?QMi+WFGKn+7CJ/y8OvARkHRN9nGrJ2vR7WNLr+SXd86qP8xh5iu3UoGcMf6X?= =?us-ascii?Q?QVMGkCzim5ukoXJS2iq7trXqMMsdXWkS06PKUqPJfxeDcU/uJbCtHC6dxyIt?= =?us-ascii?Q?1qIP7hYv4R8BF8VQ2Ya13iQtP3U/TpFvYHqkyx+mRYCquTSCJ9tWOG39lMHF?= =?us-ascii?Q?lNc2LoZG4MQagcEzHY7/YX7VVFQ9eojAUwbSD6DCZnD7OANI+/drmIduwryi?= =?us-ascii?Q?Cx2jLKutDpd+PUex0gN/mHAm1aSGLdVrbAuurP1Bh809PFJhqweU4O3HjOzB?= =?us-ascii?Q?6WVo/5cLdlzHhQmH9ZkRyj7sGJoKQ4yEricZP6+4pQPgnQAxxlZzmSD5lUyW?= =?us-ascii?Q?IH1jvIdH6XVvj2pP0DROrLKZ/vo0m4qa0EETv/fqUmdfcYcJ9d0JMXxG+Akt?= =?us-ascii?Q?0OE0SLJNLkW0qBbbRRjsIyQcxE/UOM8foozgnhAU+ia+xOyczHjmpAwwfalI?= =?us-ascii?Q?c1npDR9/1Wnh3vfynt/XtzJC77Gmtx9gYZL7QY5O5X0+Fnmp3nhrd94ruKHN?= =?us-ascii?Q?dxSbp4EI3el/Y12qDYzherwhuqzDQNqJNFsuR1iVSabtzFh9y37ZQCrwNpT2?= =?us-ascii?Q?muFe980IEJWGd/hnseTRZH3+LFhbrXv3z4PtKh2CRSAdYXd2EC4r6YKWDhRS?= =?us-ascii?Q?mA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3227B389DD755F787C045EA0FC5C9DM6PR11MB3227namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3227.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4e9d4e3-0b31-4926-3d6c-08daa7ad7c5e X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2022 15:14:38.3765 (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: rhWLgUjUROYLcpFx+5Kf4SurxYX7hvTeevq8W0UGx44pM92hK9P8fWmavcCuTbgXXI1jFT2k+TQ5YM4unRwsrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6836 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 --_000_DM6PR11MB3227B389DD755F787C045EA0FC5C9DM6PR11MB3227namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DPDK Deprecation Notice Review Meeting 2022-09-30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DPDK Community member met and reviewed the status of the DPDK deprecation notices prior to the RC1 deadline. The source document is https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst copied below. Key messages: * We should do periodic community reviews of the deprecation notices and in particular at the start of the yy.11 cycle. * We could group long standing deprecations notices at the start of the doc in a section that is separate from the notices that are specific to the current yy.11. * Notes to the notices are inline below and prefixed with ">". Deprecation Notices ------------------- * kvargs: The function ``rte_kvargs_process`` will get a new parameter for returning key match count. It will ease handling of no-match case. > Won't make it into this release. * eal: RTE_FUNC_PTR_OR_* macros have been marked deprecated and will be rem= oved in the future. Applications can use ``devtools/cocci/func_or_ret.cocci`` to update their code. > This is still relevant to current and future releases. * eal: The function ``rte_eal_remote_launch`` will return new error codes after read or write error on the pipe, instead of calling ``rte_panic``. > partially done may need other rte_panic removed * rte_atomicNN_xxx: These APIs do not take memory order parameter. This doe= s not allow for writing optimized code for all the CPU architectures suppor= ted in DPDK. DPDK has adopted the atomic operations from https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html. These operations must be used for patches that need to be merged in 20.08 onwar= ds. This change will not introduce any performance degradation. > This is still relevant to current and future releases. * rte_smp_*mb: These APIs provide full barrier functionality. However, many use cases do not require full barriers. To support such use cases, DPDK h= as adopted atomic operations from https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html. These operations and a new wrapper ``rte_atomic_thread_fence`` instead of ``__atomic_thread_fence`` must be used for patches that need to be merged= in 20.08 onwards. This change will not introduce any performance degradation= . > This is still relevant to current and future releases. * bus: The ``dev->device.numa_node`` field is set by each bus driver for every device it manages to indicate on which NUMA node this device lies. When this information is unknown, the assigned value is not consistent across the bus drivers. In DPDK 22.11, the default value will be set to -1 by all bus drivers when the NUMA information is unavailable. > This is in progress. * kni: The KNI kernel module and library are not recommended for use by new applications - other technologies such as virtio-user are recommended ins= tead. Following the DPDK technical board `decision `= _ and `refinement `_: * Some deprecation warnings will be added in DPDK 22.11. * The KNI example application will be removed from DPDK 22.11. * The KNI kernel module, library and PMD will be removed from the DPDK 23= .11. > We should add a compilation and/or dmesg deprecation warning @ferruh * lib: will fix extending some enum/define breaking the ABI. There are mult= iple samples in DPDK that enum/define terminated with a ``.*MAX.*`` value whic= h is used by iterators, and arrays holding these values are sized with this ``.*MAX.*`` value. So extending this enum/define increases the ``.*MAX.*`= ` value which increases the size of the array and depending on how/where th= e array is used this may break the ABI. ``RTE_ETH_FLOW_MAX`` is one sample of the mentioned case, adding a new fl= ow type will break the ABI because of ``flex_mask[RTE_ETH_FLOW_MAX]`` array usage in following public struct hierarchy: ``rte_eth_fdir_flex_conf -> rte_eth_fdir_conf -> rte_eth_conf (in the mid= dle)``. Need to identify this kind of usages and fix in 20.11, otherwise this blo= cks us extending existing enum/define. One solution can be using a fixed size array instead of ``.*MAX.*`` value= . > We need some documentation, in the contributors guide or the programmers = guide on how to deal with this. There is general agreement that having a MAX va= lue in an enum is a bad idea for ABI but developers like using this as a sent= inal or array size value so some people have been using "reserved" padding val= ues in enums to workaround this restrictions. The community should agree, and document, what is acceptable. * ethdev: The function ``rte_eth_set_queue_rate_limit`` takes ``rate`` in M= bps. The queue rate is limited to 64 Gbps because declared as ``uint16_t``. The ``rate`` parameter will be modified to ``uint32_t`` in DPDK 22.11 so that it can work for more than 64 Gbps. > Patch submitted need ack from Intel and NXT. > https://patches.dpdk.org/project/dpdk/patch/1664344318-3594-1-git-send-em= ail-skoteshwar@marvell.com/ * ethdev: Since no single PMD supports ``RTE_ETH_RX_OFFLOAD_HEADER_SPLIT`` offload and the ``split_hdr_size`` field in structure ``rte_eth_rxmode`` to enable per-port header split, they will be removed in DPDK 22.11. The per-queue Rx packet split offload ``RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT`` can still be used, and it is configured by ``rte_eth_rxseg_split``. > Acked and will be merge > https://patches.dpdk.org/project/dpdk/patch/20220812031313.87385-1-xuan.d= ing@intel.com/ * ethdev: Announce moving from dedicated modify function for each field, to using the general ``rte_flow_modify_field`` action. > This is still relevant to current and future releases. * ethdev: The flow API matching pattern structures, ``struct rte_flow_item_= *``, should start with relevant protocol header. Some matching pattern structures implements this by duplicating protocol = header fields in the struct. To clarify the intention and to be sure protocol he= ader is intact, will replace those fields with relevant protocol header struct= . In v21.02 both individual protocol header fields and the protocol header = struct will be added as union, target is switch usage to the protocol header by = time. In v21.11 LTS, protocol header fields will be cleaned and only protocol h= eader struct will remain. > Some work still ongoing, may need to go into RC2 but should be in RC1 > Best effort for RC1, and then list any missing structs in the docs. * ethdev: Queue specific stats fields will be removed from ``struct rte_eth= _stats``. Mentioned fields are: ``q_ipackets``, ``q_opackets``, ``q_ibytes``, ``q_o= bytes``, ``q_errors``. Instead queue stats will be received via xstats API. Current method suppo= rt will be limited to maximum 256 queues. Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed. > This deprecation notice will stay. * ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11. > Some have been removed as part of a patch series. The deprecation notice = will need to change to reflect. * ethdev: The use of attributes ``ingress`` / ``egress`` in "transfer" flow= s is deprecated as ambiguous with respect to the embedded switch. The use o= f these attributes will become invalid starting from DPDK 22.11. > There is a patch in progress for this. * ethdev: Actions ``OF_SET_MPLS_TTL``, ``OF_DEC_MPLS_TTL``, ``OF_SET_NW_TTL= ``, ``OF_COPY_TTL_OUT``, ``OF_COPY_TTL_IN`` are deprecated as not supported b= y any PMD, so they will be removed in DPDK 22.11. > Patch has been submitted * ethdev: Actions ``OF_DEC_NW_TTL``, ``SET_IPV4_SRC``, ``SET_IPV4_DST``, ``SET_IPV6_SRC``, ``SET_IPV6_DST``, ``SET_TP_SRC``, ``SET_TP_DST``, ``DEC_TTL``, ``SET_TTL``, ``SET_MAC_SRC``, ``SET_MAC_DST``, ``INC_TCP_SEQ= ``, ``DEC_TCP_SEQ``, ``INC_TCP_ACK``, ``DEC_TCP_ACK``, ``SET_IPV4_DSCP``, ``SET_IPV6_DSCP``, ``SET_TAG``, ``SET_META`` are marked as legacy and superseded by the generic MODIFY_FIELD action. The legacy actions should be deprecated in 22.07, once MODIFY_FIELD alternative is implemented. The legacy actions should be removed in DPDK 22.11. > Should be grouped with ??? notice above, and the specific drivers named. > There was a proposal to have an earlier removal date, at the very start > of the xx.11 period so that code is changed/tested in time for RC1. * ethdev: The enum ``rte_eth_event_ipsec_subtype`` will be extended to add new subtype values ``RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY``, ``RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY`` and ``RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY`` in DPDK 22.11. > Merged * bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type`` enum will be deprecated and instead use fixed array size when required to allow for future enum extension. Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this `RFC `__= . New members will be added in ``rte_bbdev_driver_info`` to expose PMD queue topology inspired by this `RFC `__= . New member will be added in ``rte_bbdev_driver_info`` to expose the device status as per this `RFC `__= . This should be updated in DPDK 22.11. > This involves several patches, some will be merged * cryptodev: Hide structures ``rte_cryptodev_sym_session`` and ``rte_cryptodev_asym_session`` to remove unnecessary indirection between session and the private data of session. An opaque pointer can be exposed directly to application which can be attached to the ``rte_crypto_op``. > Patches submitted. One issue with security below. * cryptodev: The function ``rte_cryptodev_cb_fn`` will be updated to have another parameter ``qp_id`` to return the queue pair ID which got error interrupt to the application, so that application can reset that particular queue pair. > Will be removed without any objections(? note unclear) * security: Hide structure ``rte_security_session`` and expose an opaque pointer for the private data to the application which can be attached to the packet while enqueuing. > Kontantin has a comment (should be merged in RC2) * eventdev: The function ``rte_event_crypto_adapter_queue_pair_add`` will accept configuration of type ``rte_event_crypto_adapter_queue_conf`` inst= ead of ``rte_event``, similar to ``rte_event_eth_rx_adapter_queue_add`` signa= ture. Event will be one of the configuration fields, together with additional vector parameters. > Patches ready. Comment required from Abhinandan * eventdev: The function pointer declaration ``eventdev_stop_flush_t`` will be renamed to ``rte_eventdev_stop_flush_t`` in DPDK 22.11. > Patch available and will be merged today * eventdev: The element ``*u64s`` in the structure ``rte_event_vector`` is deprecated and will be replaced with ``u64s`` in DPDK 22.11. > Patch available and will be merged today * eventdev: The structure ``rte_event_vector`` will be modified to include ``elem_offset:12`` bits taken from ``rsvd:15``. The ``elem_offset`` defin= es the offset into the vector array from which valid elements are present. The difference between ``rte_event_vector::nb_elem`` and ``rte_event_vector::elem_offset`` gives the number of valid elements left to process from the ``rte_event_vector::elem_offset``. > Patch is merged. Should remove deprecation docs. * metrics: The function ``rte_metrics_init`` will have a non-void return in order to notify errors instead of calling ``rte_exit``. > Patch submitted by Bruce * raw/dpaa2_cmdif: The ``dpaa2_cmdif`` rawdev driver will be deprecated in DPDK 22.11, as it is no longer in use, no active user known. > Drop from deprecations. --_000_DM6PR11MB3227B389DD755F787C045EA0FC5C9DM6PR11MB3227namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

DPDK Deprecatio= n Notice Review Meeting 2022-09-30

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 

DPDK Community = member met and reviewed the status of the DPDK

deprecation not= ices prior to the RC1 deadline. The source document

is https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst

copied below.

 

Key messages:

 

* We should do = periodic community reviews of the deprecation notices

  and in p= articular at the start of the yy.11 cycle.

* We could grou= p long standing deprecations notices at the start of

  the doc = in a section that is separate from the notices that are

  specific= to the current yy.11.

* Notes to the = notices are inline below and prefixed with ">". 

 

 

Deprecation Not= ices

---------------= ----

* kvargs: The f= unction ``rte_kvargs_process`` will get a new parameter

  for retu= rning key match count. It will ease handling of no-match case.

 

> Won't make= it into this release.

 

* eal: RTE_FUNC= _PTR_OR_* macros have been marked deprecated and will be removed=

  in the f= uture. Applications can use ``devtools/cocci/func_or_ret.cocci``=

  to updat= e their code.

 

> This is st= ill relevant to current and future releases.

 

* eal: The func= tion ``rte_eal_remote_launch`` will return new error codes

  after re= ad or write error on the pipe, instead of calling ``rte_panic``.=

 

> partially = done may need other rte_panic removed

 

* rte_atomicNN_= xxx: These APIs do not take memory order parameter. This does

  not allo= w for writing optimized code for all the CPU architectures supported

  in DPDK.= DPDK has adopted the atomic operations from

  https://= gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html. These=

  operatio= ns must be used for patches that need to be merged in 20.08 onwards.

  This cha= nge will not introduce any performance degradation.

 

> This is st= ill relevant to current and future releases.

 

* rte_smp_*mb: = These APIs provide full barrier functionality. However, many

  use case= s do not require full barriers. To support such use cases, DPDK has

  adopted = atomic operations from

  https://= gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html. These=

  operatio= ns and a new wrapper ``rte_atomic_thread_fence`` instead of

  ``__atom= ic_thread_fence`` must be used for patches that need to be merged in

  20.08 on= wards. This change will not introduce any performance degradation.

 

> This is st= ill relevant to current and future releases.

 

* bus: The ``de= v->device.numa_node`` field is set by each bus driver for

  every de= vice it manages to indicate on which NUMA node this device lies.=

  When thi= s information is unknown, the assigned value is not consistent

  across t= he bus drivers.

  In DPDK = 22.11, the default value will be set to -1 by all bus drivers

  when the= NUMA information is unavailable.

 

> This is in= progress.

 

* kni: The KNI = kernel module and library are not recommended for use by new

  applicat= ions - other technologies such as virtio-user are recommended instead.=

  Followin= g the DPDK technical board

  `decisio= n <https://mails.dpdk.org/archives/dev/2021-January/197077.html>`_

  and `ref= inement <http://mails.dpdk.org/archives/dev/2022-June/243596.html>`_:=

 

* Some deprecat= ion warnings will be added in DPDK 22.11.

  * The KN= I example application will be removed from DPDK 22.11.

  * The KN= I kernel module, library and PMD will be removed from the DPDK 23.11.<= /o:p>

 

> We should = add a compilation and/or dmesg deprecation warning @ferruh

 

 

* lib: will fix= extending some enum/define breaking the ABI. There are multiple=

  samples = in DPDK that enum/define terminated with a ``.*MAX.*`` value which is<= /o:p>

  used by = iterators, and arrays holding these values are sized with this

  ``.*MAX.= *`` value. So extending this enum/define increases the ``.*MAX.*``

  value wh= ich increases the size of the array and depending on how/where the

  array is= used this may break the ABI.

  ``RTE_ET= H_FLOW_MAX`` is one sample of the mentioned case, adding a new flow

  type wil= l break the ABI because of ``flex_mask[RTE_ETH_FLOW_MAX]`` array=

  usage in= following public struct hierarchy:

  ``rte_et= h_fdir_flex_conf -> rte_eth_fdir_conf -> rte_eth_conf (in the middle)= ``.

  Need to = identify this kind of usages and fix in 20.11, otherwise this blocks

  us exten= ding existing enum/define.

  One solu= tion can be using a fixed size array instead of ``.*MAX.*`` value.

 

> We need so= me documentation, in the contributors guide or the programmers guide

  on how t= o deal with this. There is general agreement that having a MAX value

  in an en= um is a bad idea for ABI but developers like using this as a sentinal<= /o:p>

  or array= size value so some people have been using "reserved" padding val= ues

  in enums= to workaround this restrictions. The community should agree, and

  document= , what is acceptable.

 

* ethdev: The f= unction ``rte_eth_set_queue_rate_limit`` takes ``rate`` in Mbps.=

  The queu= e rate is limited to 64 Gbps because declared as ``uint16_t``.

  The ``ra= te`` parameter will be modified to ``uint32_t`` in DPDK 22.11

  so that = it can work for more than 64 Gbps.

 

> Patch subm= itted need ack from Intel and NXT.

> https://pa= tches.dpdk.org/project/dpdk/patch/1664344318-3594-1-git-send-email-skoteshw= ar@marvell.com/

 

* ethdev: Since= no single PMD supports ``RTE_ETH_RX_OFFLOAD_HEADER_SPLIT``

  offload = and the ``split_hdr_size`` field in structure ``rte_eth_rxmode``=

  to enabl= e per-port header split, they will be removed in DPDK 22.11.

  The per-= queue Rx packet split offload ``RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT``

  can stil= l be used, and it is configured by ``rte_eth_rxseg_split``.

 

> Acked and = will be merge

> https://pa= tches.dpdk.org/project/dpdk/patch/20220812031313.87385-1-xuan.ding@intel.co= m/

 

* ethdev: Annou= nce moving from dedicated modify function for each field,=

  to using= the general ``rte_flow_modify_field`` action.

 

> This is st= ill relevant to current and future releases.

 

* ethdev: The f= low API matching pattern structures, ``struct rte_flow_item_*``,=

  should s= tart with relevant protocol header.

  Some mat= ching pattern structures implements this by duplicating protocol header

  fields i= n the struct. To clarify the intention and to be sure protocol header<= /o:p>

  is intac= t, will replace those fields with relevant protocol header struct.

  In v21.0= 2 both individual protocol header fields and the protocol header struct

  will be = added as union, target is switch usage to the protocol header by time.=

  In v21.1= 1 LTS, protocol header fields will be cleaned and only protocol header=

  struct w= ill remain.

 

> Some work = still ongoing, may need to go into RC2 but should be in RC1

> Best effor= t for RC1, and then list any missing structs in the docs.=

 

* ethdev: Queue= specific stats fields will be removed from ``struct rte_eth_stats``.<= /o:p>

  Mentione= d fields are: ``q_ipackets``, ``q_opackets``, ``q_ibytes``, ``q_obytes``,

  ``q_erro= rs``.

  Instead = queue stats will be received via xstats API. Current method support

  will be = limited to maximum 256 queues.

  Also com= pile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.<= /span>

 

> This depre= cation notice will stay.

 

* ethdev: Items= and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are

  deprecat= ed as hard-to-use / ambiguous and will be removed in DPDK 22.11.=

 

> Some have = been removed as part of a patch series. The deprecation notice will

  need to = change to reflect.

 

* ethdev: The u= se of attributes ``ingress`` / ``egress`` in "transfer" flows

  is depre= cated as ambiguous with respect to the embedded switch. The use of

  these at= tributes will become invalid starting from DPDK 22.11.

 

> There is a= patch in progress for this.

 

 

* ethdev: Actio= ns ``OF_SET_MPLS_TTL``, ``OF_DEC_MPLS_TTL``, ``OF_SET_NW_TTL``,<= /span>

  ``OF_COP= Y_TTL_OUT``, ``OF_COPY_TTL_IN`` are deprecated as not supported by

  any PMD,= so they will be removed in DPDK 22.11.

 

> Patch has = been submitted

 

* ethdev: Actio= ns ``OF_DEC_NW_TTL``, ``SET_IPV4_SRC``, ``SET_IPV4_DST``,=

  ``SET_IP= V6_SRC``, ``SET_IPV6_DST``, ``SET_TP_SRC``, ``SET_TP_DST``,

  ``DEC_TT= L``, ``SET_TTL``, ``SET_MAC_SRC``, ``SET_MAC_DST``, ``INC_TCP_SEQ``,

  ``DEC_TC= P_SEQ``, ``INC_TCP_ACK``, ``DEC_TCP_ACK``, ``SET_IPV4_DSCP``,

  ``SET_IP= V6_DSCP``, ``SET_TAG``, ``SET_META`` are marked as legacy and

  supersed= ed by the generic MODIFY_FIELD action.

  The lega= cy actions should be deprecated in 22.07, once MODIFY_FIELD

  alternat= ive is implemented.

  The lega= cy actions should be removed in DPDK 22.11.

 

> Should be = grouped with ??? notice above, and the specific drivers named.

> There was = a proposal to have an earlier removal date, at the very start

> of the xx.= 11 period so that code is changed/tested in time for RC1.=

 

 

* ethdev: The e= num ``rte_eth_event_ipsec_subtype`` will be extended to add

  new subt= ype values ``RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY``,

  ``RTE_ET= H_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY`` and

  ``RTE_ET= H_EVENT_IPSEC_SA_PKT_HARD_EXPIRY`` in DPDK 22.11.

 

> Merged

 

* bbdev: ``RTE_= BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``

  enum wil= l be deprecated and instead use fixed array size when required

  to allow= for future enum extension.

  Will ext= end API to support new operation type ``RTE_BBDEV_OP_FFT`` as per

  this `RF= C <https://patches.dpdk.org/project/dpdk/list/?series=3D22111>`__.

  New memb= ers will be added in ``rte_bbdev_driver_info`` to expose<= /p>

  PMD queu= e topology inspired by

  this `RF= C <https://patches.dpdk.org/project/dpdk/list/?series=3D22076>`__.

  New memb= er will be added in ``rte_bbdev_driver_info`` to expose

  the devi= ce status as per

  this `RF= C <https://patches.dpdk.org/project/dpdk/list/?series=3D23367>`__.

  This sho= uld be updated in DPDK 22.11.

 

> This invol= ves several patches, some will be merged

 

* cryptodev: Hi= de structures ``rte_cryptodev_sym_session`` and

  ``rte_cr= yptodev_asym_session`` to remove unnecessary indirection between=

  session = and the private data of session. An opaque pointer can be exposed

  directly= to application which can be attached to the ``rte_crypto_op``.<= /span>

 

> Patches su= bmitted. One issue with security below.

 

* cryptodev: Th= e function ``rte_cryptodev_cb_fn`` will be updated

  to have = another parameter ``qp_id`` to return the queue pair ID

  which go= t error interrupt to the application,

  so that = application can reset that particular queue pair.

 

> Will be re= moved without any objections(? note unclear)

 

* security: Hid= e structure ``rte_security_session`` and expose an opaque=

  pointer = for the private data to the application which can be attached

  to the p= acket while enqueuing.

 

> Kontantin = has a comment (should be merged in RC2)

 

* eventdev: The= function ``rte_event_crypto_adapter_queue_pair_add`` will

  accept c= onfiguration of type ``rte_event_crypto_adapter_queue_conf`` instead

  of ``rte= _event``, similar to ``rte_event_eth_rx_adapter_queue_add`` signature.=

  Event wi= ll be one of the configuration fields,

  together= with additional vector parameters.

 

> Patches re= ady. Comment required from Abhinandan

 

* eventdev: The= function pointer declaration ``eventdev_stop_flush_t``

  will be = renamed to ``rte_eventdev_stop_flush_t`` in DPDK 22.11.

 

> Patch avai= lable and will be merged today

 

* eventdev: The= element ``*u64s`` in the structure ``rte_event_vector``<= /p>

  is depre= cated and will be replaced with ``u64s`` in DPDK 22.11.

 

> Patch avai= lable and will be merged today

 

* eventdev: The= structure ``rte_event_vector`` will be modified to include

  ``elem_o= ffset:12`` bits taken from ``rsvd:15``. The ``elem_offset`` defines

  the offs= et into the vector array from which valid elements are present.<= /span>

  The diff= erence between ``rte_event_vector::nb_elem`` and

  ``rte_ev= ent_vector::elem_offset`` gives the number of valid elements left

  to proce= ss from the ``rte_event_vector::elem_offset``.

 

> Patch is m= erged. Should remove deprecation docs.

 

* metrics: The = function ``rte_metrics_init`` will have a non-void return=

  in order= to notify errors instead of calling ``rte_exit``.

 

> Patch subm= itted by Bruce

 

* raw/dpaa2_cmd= if: The ``dpaa2_cmdif`` rawdev driver will be deprecated<= /p>

  in DPDK = 22.11, as it is no longer in use, no active user known.

 

> Drop from = deprecations.

 

 

 

--_000_DM6PR11MB3227B389DD755F787C045EA0FC5C9DM6PR11MB3227namp_--