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 4BFF446257 for ; Tue, 18 Feb 2025 10:32:58 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D49A402CF; Tue, 18 Feb 2025 10:32:57 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) by mails.dpdk.org (Postfix) with ESMTP id 596B4402BB for ; Tue, 18 Feb 2025 10:32:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739871175; x=1771407175; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YYgwKNUhDrdVh0lwQQkfDFtszoeE1XrhWamnPoukKUo=; b=MU0D2Fi7ui/CvvFlR8ILsJqAzE7Cg1LLG21sDZyRg0jcIrjrt/kXg8Cd 4ObDBCW5S0bYwo9FCDbwpe0Tne5dLW41lFMQl75P8EpsqmPw5sRavXjcY XAMS6a1ILQLaPgv1z/DIQhJRzuq+pmjb/MhfDtVdPkCwHsl9dvHm5vIZs 8+dSI546KlKrSH0oUJtOo4avkVEi1QiTmvuM6oMkLzqOar0ZtuATxWMEA wj3bL6NJO4d6X2UxwmqRDL9YZ7GOoTHtpk4Y2IBQG6B7Uzn9MtzF2+DLq RCOJyaAySN+T43MdqaWSu5BxvTyM3k/tM/MIS6gzlXbzImQWILVhFqW+k Q==; X-CSE-ConnectionGUID: 2ftewgcjQTKNABTaeeUP7A== X-CSE-MsgGUID: ZZA6VXfcR8C+eET37cRr8g== X-IronPort-AV: E=McAfee;i="6700,10204,11348"; a="44483654" X-IronPort-AV: E=Sophos;i="6.13,295,1732608000"; d="scan'208,217";a="44483654" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2025 01:32:52 -0800 X-CSE-ConnectionGUID: 9LMgWVaJREuwoxyMUV3Afg== X-CSE-MsgGUID: gpojr0e6QQ+wR5q9zKoy9g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208,217";a="115237851" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2025 01:32:52 -0800 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 18 Feb 2025 01:32:51 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14 via Frontend Transport; Tue, 18 Feb 2025 01:32:51 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.45) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Tue, 18 Feb 2025 01:32:51 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l2a/jewdj8tcYnZQ7eTF3f3BBKLLPqmfiMxCTceYaiuZ5R29Lth1dGanzd3xzILqco1/v+Q338Mt+y0KeI/PWj0IJ1RKquaiy54l4/51gZiB6cX66rOmM/baFl3WfYpyUChH8eQ1Jde4KPW0Cf+A5eV8Tq8a/v7IQCZ93ayEUWG7mQDsaLs0J4MVIr+qPS/P6Z5Fmu3hIFqPoQClyi/wW45ubMOtvd6VV2ZJ2ViOGfQuBkb852noEXh0r4DLV6ivJQVX3lJaQM/zGh939dBKJrOMwqInO2ZYEofaI0DbqrqtDIwhjZ905Lh+XNI0Fq8xBNFwo0JxyKapgNmSMd1CiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=YYgwKNUhDrdVh0lwQQkfDFtszoeE1XrhWamnPoukKUo=; b=JHVnQ7eg7xb7OT6vP4Gp+BzQojmGusYwogFgjpRJm4IGkdbcLiweLxsMrzSYkKTT+u+NxbwjpilBwPAp+3uQJVAJlBfYbrUS4pAVgFV1nf8DSFpfLevabjLVUUEZ5YDMTcCycGr3iR6JzCg843TDEi9kfDwCTTo8RSqqRNRgGghYVl+XyrlQmIOCdPLmZzXt7WuUuMUOpajRslGVIrL5wy0hx1zJ9zNn1pATXgdFXjDu51rwmLSYxuc0i6DCRSL4DP9MaX3xbe4e0+CpanmAnDjyTlwV2ZXEYzwXvvIo2/SEEdvxl3Kp2lxZ7KPGM5jjCEla4HsiW6EZRzbEnT1yuQ== 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 PH8PR11MB6803.namprd11.prod.outlook.com (2603:10b6:510:1cb::12) by DS7PR11MB6013.namprd11.prod.outlook.com (2603:10b6:8:70::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8445.19; Tue, 18 Feb 2025 09:32:08 +0000 Received: from PH8PR11MB6803.namprd11.prod.outlook.com ([fe80::8680:ff9f:997:18b4]) by PH8PR11MB6803.namprd11.prod.outlook.com ([fe80::8680:ff9f:997:18b4%7]) with mapi id 15.20.8445.015; Tue, 18 Feb 2025 09:32:00 +0000 From: "Van Haaren, Harry" To: "Zhang, Changchun" , Stephen Hemminger CC: NAGENDRA BALAGANI , "users@dpdk.org" Subject: Re: [External] : Re: Query Regarding Race Condition Between Packet Reception and Device Stop in DPDK Thread-Topic: [External] : Re: Query Regarding Race Condition Between Packet Reception and Device Stop in DPDK Thread-Index: Adt+vEdloaqObPP2T4u6OUiIi+rKNwAA6AYrAKt0fAAAAFg3AAAAQuiAAB0rMLg= Date: Tue, 18 Feb 2025 09:32:00 +0000 Message-ID: References: <20250217110652.2f3eb077@hermes.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: 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: PH8PR11MB6803:EE_|DS7PR11MB6013:EE_ x-ms-office365-filtering-correlation-id: 9ee9eea3-2247-4077-eefc-08dd4fff18b1 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|376014|1800799024|38070700018|7053199007|8096899003; x-microsoft-antispam-message-info: =?iso-8859-1?Q?P7E6/Ur18BT6CPjTq2mchIVngnbjXTIiz4YtCAdFTL21fVvBp8P5vXc61y?= =?iso-8859-1?Q?5/di3ecEQzHYDb1OOqbqCzw5uleFBav0/LbGVVraQ/1Hb/mbLkS6YIdOWk?= =?iso-8859-1?Q?zAjqz2qkjs5aef3/mEY0GrIYu/vBkfGmSj3EEshXU5/AebWSEiSs2j7ezn?= =?iso-8859-1?Q?MYMvm199ne7kKzxmhYIRYIUX3dXP+nCYggTsB4/+AzA8OISyXdAu77+nOm?= =?iso-8859-1?Q?XhEbRpQUWgutHisl6NN/1+Mi4S4kmWUbsZpANd9lELblqHNbqZBDsKLoad?= =?iso-8859-1?Q?jVvaR4oZpJ7OezbiHKr3elXn/lbt25K4w+ylRuGiEahSe+uc4wFWCGfFmU?= =?iso-8859-1?Q?nNPFiffhiDyoUNpiSIi0aFYCN3F4zefGcVCbxjd8jzI0CrmyTFe9TN+4Wa?= =?iso-8859-1?Q?L4Y1MhwbA2meZNd6wFM8CHKYw5swlAbR2nz40BKVv5wf8INXzQg+uTNJMy?= =?iso-8859-1?Q?tQLBcbuBqOuRvBzYLF56kUG0uCIURtRdT4D1jWWjklWil9chS0Yx3bZnPG?= =?iso-8859-1?Q?kbIReXzgmxUGh+KYr/sajTLpDVr6N297Izn4DiRJKpj0Y4MLA7fHM+QcWb?= =?iso-8859-1?Q?MaR66yaUITsLwa52KiyYm/EOe+OqYNgMJABBiCO5iEytGtEy/iBYu93m9J?= =?iso-8859-1?Q?EZwTmpIiGuzqx83ie2nsNC7spD93zXDsbiSV2ZbvHe4FpaXc+yBrIBkTTP?= =?iso-8859-1?Q?54tLIBJTv5gZ192p+uVE5r7uXKgeWd86vKukx3Zk+NMgtKPEQwsC5dzfGY?= =?iso-8859-1?Q?RMDXovQ+RgJssbjsVSmnJUvP68VGC95wXXJu5HiZvsZ1HTIfhUsWGA+VHO?= =?iso-8859-1?Q?MO5w/ax5FTVlkxVGZDlat6/gH7crq7hCj5Ur67iQWYd2s/qW9x87j8SlWd?= =?iso-8859-1?Q?L0maa739NEzV+TAaJo1GdZ7VJiQqVl0OlWy2v5AHT5S2QtdQTwWuOl9sFv?= =?iso-8859-1?Q?e6MbjO/X1/2FcXh6UMiky9A2rJ8Zc0nMPySiHFPgD7K7iohpGOdnfH/MEP?= =?iso-8859-1?Q?qGhAGfhfevbzQtdrk/c6KBDdcqS9spGYLtLiAZrdSk4MguwY0QzcUrZcMP?= =?iso-8859-1?Q?Vjgf49V+3HhxCqVQn2Ym0TKRX4uxXXVYxtDQRnN5N3OGeqXAsJq7dz7//o?= =?iso-8859-1?Q?88E+vChGPq5EBK9rzDn2bturbZl/tRhrAXxSXhhrUXx+ktvlKKXxIwrV9H?= =?iso-8859-1?Q?5NR4BlgOpz4JSamr6NRM70Qel6cXH6tU2AV9tkGffEl/zLutVT8mbI/WOg?= =?iso-8859-1?Q?SK/Om+DQQjFTtY6I2Xlv1YjNlzbkKFETaQrmCK1WF9x7U1d/7/TWjPuqLD?= =?iso-8859-1?Q?9I1AMRv/L7HYZ02kFunSlAc1cy5YOxt6/NntP9nKp+Y0S/qEuaIwpaPp+1?= =?iso-8859-1?Q?UaPlFpAWT58n97YotGClryZuvoj/za+DSNXSWCkFg2pfE3MrXxhBnYMK/R?= =?iso-8859-1?Q?/rMupqFVW+xiPNBSKiU/yQUBWFMmLNBke2yLjA=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH8PR11MB6803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(376014)(1800799024)(38070700018)(7053199007)(8096899003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?T9ayLFY4ZX4qv7j3EmGHlF4+GTnHCF15rQYr4ri+wttpNrJw0Q5Nk2XHLV?= =?iso-8859-1?Q?c2aSpZE+663E32PMp4zcwzUpmVJ5Xl4JGbF2qKGWSsfAS49/1xTpUpzdis?= =?iso-8859-1?Q?Vjc6z00alA648vrsz/BmaZsdpIcB6o4vFlHppZq4Dsw3rDPd4K1NzFA4uE?= =?iso-8859-1?Q?1dVFqGT0vG4gC6kpp6zxScQfQnKK3U53Y84HHIwusxeH7i8kPC0K/DOTBr?= =?iso-8859-1?Q?324M+xqMk7Ewrcqa+ffr0S4drGCGWwLhECfiJ1In38PaD4BB+adsS31Zj1?= =?iso-8859-1?Q?a0tFucXLboLInHCYF/KCiiNWlp9+pWoz4yuTtkbh3RyLDgAFrl26XrslO1?= =?iso-8859-1?Q?ZNnviYGXpxQMD4VZ+oDe0amDnoQxVlLqCLlVBY5eweE1wugHnozribBeUg?= =?iso-8859-1?Q?5cS0mqx9KktSi1nNcu/yAyAG8D4rbJbE2az5whFhhM8OjrwvdZwcASGXBS?= =?iso-8859-1?Q?YwY+dGMSNPZbm3vKjNGd7LwBXRLxWqkKB2ckkJUAFDyuXGmLfJpPZWa+eu?= =?iso-8859-1?Q?Zl4F8l23SxLOM8BEgrspKBdtA7mu8C3/HkZi/eYfW7C1lYIRn7R2w4+HYL?= =?iso-8859-1?Q?mVZ9vdXcGqW0i9ePUUqGcBgs4WacZk63dzS2LQiOjJ8KAmG/wlrktp/HQI?= =?iso-8859-1?Q?cRzUZJg93fSCWqZorqv7FiJlwCEqosa8nIT/z+3ggWJHJuW5bU8O7+dtlz?= =?iso-8859-1?Q?7KxC6rRXzbXjeo1Wb4oOWdPTXoLnNBMt9OYGd/ZbmNOtSFdGT6VU9Rgnwg?= =?iso-8859-1?Q?DpSn5wAWhTl0vibq1x2YoqACxfezuXSgNe6BzYS4sDGnyp9Hley/o75rSW?= =?iso-8859-1?Q?vrTwzBZkfAm/SXk/nZFlf4kZy8XGNbSB3QGAHCyYVnPD7mwJIYlG+UfcYj?= =?iso-8859-1?Q?JeNcQ3EEdMOQkJUSaFLp2M9f0TaNKkNq9pUviKpzunsyjR3KoNdLnB5xxG?= =?iso-8859-1?Q?JGivYO055Zx/IsvkAj30/hQgYcW/LAY8GF/veZuUcSFyGXHnrLZCGPszgB?= =?iso-8859-1?Q?6jXjzWMLqPA8+J8HWxTYTDd6oJCaRt4ND29gotnBGmsJVTl3qIk8aQ4tN2?= =?iso-8859-1?Q?vLdMrt54WvN0z3QFLN/DqhFWxDKUXpxajxgoBlkJgEMWaVuZbzdaBv3d/+?= =?iso-8859-1?Q?Is52Cdw1nLOp9JfMOKAXhUtjYbTNu83PgznST3Gplfmrm1cjoaSnAxSwLP?= =?iso-8859-1?Q?u5pGcZvlTOLPaP9G00E52+VZtkierZ9SHxRAFEvEcGCghEThiYjjAIfQ5V?= =?iso-8859-1?Q?w/JKZdWkizgmcT8KlFS3sSwSy+z+joARJzAT1isXshLvWGF94lV5MdSuOn?= =?iso-8859-1?Q?dYPrLY2j2+ypiJ1g3yaw2qILLivrSkvDfoQTW0nij0FPZkrCNeT1qCKYOr?= =?iso-8859-1?Q?RUl0uEXrQE+JFTDi4/LLcgngfj3nHiZA+cvUPVJpd7lrrfJtLTiPh8ukQ9?= =?iso-8859-1?Q?BtpnSuMuSp23t6gAlY0/UtXomhPv8TpMag0g/aAE8hV4CBLymVIOMoeFw3?= =?iso-8859-1?Q?jHPPlTEafBy/D04IGvV3RsAZkp5gwKqnvofPwT4FLTQxL1v06Wr+fRGmfz?= =?iso-8859-1?Q?dcrfnHuPFgFx3qNa6ueR49vHCZ61sgphJE6JyvZvg0dSJO/g8CcAzJHbi1?= =?iso-8859-1?Q?PmDkX/bzKvWzhhf82IsMQOtT4KIstrEWzu?= Content-Type: multipart/alternative; boundary="_000_PH8PR11MB6803449A4116886B2435C0B2D7FA2PH8PR11MB6803namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB6803.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ee9eea3-2247-4077-eefc-08dd4fff18b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2025 09:32:00.5693 (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: UPhWYxYxuiMAjbLmd0qTTpS5RM7PLT44DlWwyg5erjsSPeHgEIpMYe6vQiTh7zYFKfLlBCGhuUjRy+YqRm7CU49zEgkJx0WI+B9PiVmWnLc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR11MB6013 X-OriginatorOrg: intel.com X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --_000_PH8PR11MB6803449A4116886B2435C0B2D7FA2PH8PR11MB6803namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Side note; please "reply inline" in plaint text when sending to mailing lis= ts, it allows future readers to see the context of your question when readi= ng the reply. > From: Changchun Zhang > Sent: Monday, February 17, 2025 7:14 PM > To: Stephen Hemminger > Cc: Van Haaren, Harry ; NAGENDRA BALAGANI ; users@dpdk.org > Subject: Re: [External] : Re: Query Regarding Race Condition Between Pack= et Reception and Device Stop in DPDK > > Okay, so here the issue is still rte_eth_dev_stop(), but not rte_eth_dev_= rx_queue_stop(), right? I mean, as long as not calling rte_eth_dev_stop() o= n control path, is it safe to call rte_eth_dev_rx_queue_stop/rte_eth_dev_rx= _queue_start on control path while fast path keeps calling rte_eth_rx_burst= ()? I see Stephen has already directly answered your question - but perhaps the= below is interesting to expand beyond the exact question being asked. Instead of answering specific questions like above, allow me to explain the= "mental model" around how I think about ports/queues and threads using the= m. - Each Queue (rx or tx, doesn't matter) is an entity that can be polled by = a dataplane thread. No control plane actions (e.g. start/stop/reset) may be= active if the queue is polled! - Each Queue depends on a port (that it logically belongs to). That port mu= st be started for the queue to be usable from the dataplane thread. - Each Queue is an individual object: different dataplane threads can poll = different queues without any "interference" (allowing one queue to restart,= while another STAYS in use) For specific use-cases, you can now logic out what is required: - Stop Queue: the dataplane thread MUST NOT poll if another thread is opera= ting on the the same queue. - Stop Port: All queues must be stopped before the port can be stopped. The= refore, all dataplane threads must stop using the queues associated with th= e port. The DPDK docs e.g. rte_eth_dev_start: https://doc.dpdk.org/api/rte__ethdev_= 8h.html#afdc834c1c52e9fb512301990468ca7c2 do have some statements around ex= pected usage: "On success, all basic functions exported by the Ethernet API= (link status, receive/transmit, and so on) can be invoked." Perhaps the do= cumentation can be improved - if you're willing to contribute, this would l= ikely be appreciated by the next developer learning the correct usage of th= ese APIs? As folks on list may know, I've been using the Rust language for a number o= f years, and it has some very nice properties around encoding these types o= f details at the API layer, and putting compile-time (or runtime - depends = on implementation) enforcement on these API constraints. This was presented= at DPDK Userspace '23, with the Rust + DPDK Ethdev part of the talk being = relevant to the above "mental model": this timestamp (6 minutes in) is the = start of that section: https://youtu.be/lb6xn2xQ-NQ?t=3D359 > Thanks, > Changchun Regards! -Harry --_000_PH8PR11MB6803449A4116886B2435C0B2D7FA2PH8PR11MB6803namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Side note; please "reply inline" in plaint text when sending to m= ailing lists, it allows future readers to see the context of your question = when reading the reply.

> From: Changchun Zhang <changchun.zhang@oracle.com>
> Sent: Monday, February 17, 2025 7:14 PM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; NAGENDRA BAL= AGANI <nagendra.balagani@oracle.com>; users@dpdk.org <users@dpdk.o= rg>
> Subject: Re: [External] : Re: Query Regarding Race Condition Between P= acket Reception and Device Stop in DPDK
>  
> Okay, so here the issue is still rte_eth_dev_stop(), but not rte_eth_d= ev_rx_queue_stop(), right? I mean, as long as not calling rte_eth_dev_stop(= ) on control path, is it safe to call rte_eth_dev_rx_queue_stop/rte_eth_dev= _rx_queue_start on control path while fast path keeps calling rte_eth_rx_burst()?

I see Stephen has already directly answered your question - but perhaps the= below is interesting to expand beyond the exact question being asked.

Instead of answering specific questions like above, allow me to explain the= "mental model" around how I think about ports/queues and threads= using them.
- Each Queue (rx or tx, doesn't matter) is an entity that can be polled by = a dataplane thread. No control plane actions (e.g. start/stop/reset) may be= active if the queue is polled!
- Each Queue depends on a port (that it logically belongs to). That port mu= st be started for the queue to be usable from the dataplane thread.
- Each Queue is an individual object: different dataplane threads can poll = different queues without any "interference" (allowing one queue t= o restart, while another STAYS in use)

For specific use-cases, you can now logic out what is required:
- Stop Queue: the dataplane thread MUST NOT poll if another thread is opera= ting on the the same queue.
- Stop Port: All queues must be stopped before the port can be stopped. The= refore, all dataplane threads must stop using the queues associated with th= e port.

The DPDK docs e.g. rte_eth_dev_start: https://doc.dpdk.org/api/rte__ethdev_= 8h.html#afdc834c1c52e9fb512301990468ca7c2 do have some statements around ex= pected usage: "On success, all basic functions exported by the Etherne= t API (link status, receive/transmit, and so on) can be invoked." Perhaps the documentation can be improved= - if you're willing to contribute, this would likely be appreciated by the= next developer learning the correct usage of these APIs?

As folks on list may know, I've been using the Rust language for a number o= f years, and it has some very nice properties around encoding these types o= f details at the API layer, and putting compile-time (or runtime - depends = on implementation) enforcement on these API constraints. This was presented at DPDK Userspace '23, with the = Rust + DPDK Ethdev part of the talk being relevant to the above "menta= l model": this timestamp (6 minutes in) is the start of that section: = https://youtu.be/lb6xn2xQ-NQ?t=3D359

> Thanks,
> Changchun

Regards! -Harry

<snip previous discussions; see https://mails.dpdk.org/archives/users/2025-February/thread.html#8122>
--_000_PH8PR11MB6803449A4116886B2435C0B2D7FA2PH8PR11MB6803namp_--