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 410CE46BF1 for ; Wed, 23 Jul 2025 14:22:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0209E40A89; Wed, 23 Jul 2025 14:22:50 +0200 (CEST) Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11023126.outbound.protection.outlook.com [40.107.162.126]) by mails.dpdk.org (Postfix) with ESMTP id A064A402CC for ; Wed, 23 Jul 2025 14:22:48 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rwsGV0/HSFZ3ANJaksAd5FM88FZZqAIAcuTKKzxcDNnKIb1e+GEKpwRjdqxIY427od1JZkPudtW4eOzoSEBIKuhH3UU/t8bXSEYRSpcd0n5fCb/H5l3YtrHMzDt1dnfRY8IlB9vUlL7mFg8E5xiK0oCayvXOv45rIATJi1cJRNwm5oMIA/+8jHFk2cOiz9/2Pl6b/n4o+H8nQjAL25wwC+2Gv5ThErNIKcT9Ae3HMUVa1OjN33ruTJtPH7SE29KLYwIgsHGm0iRXkzC82hLokptgY1ZSI8DvmcfBb7zQSwoiltfMQ5Jp3ImjyNS+3poC8WlcCgB7xulnsmXJZxevPw== 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=oLiPlKOeQPDrwEt3jvEHwNxt0oPpH45UspjG5fFPE0o=; b=XIZTA9Fdw/k8of0cOX9ile+Q/NETAARDptLWTsI7t0TjEoG74bQVPWjzCOailp1Qa+v+a1w/3virkxd1roiqRDphTXsxv3wMDECxug3mrNgV2jr9/pcUHNK6NndP/CRgLPqRmCi6iCgbYU5vOtV3WVOEogCpFCS0uzDOi8tpttCmDA/e6KdD1EflMDl1ZOEFdUSa9gfFE8Y9VGujyBMoh5uBoMxEvahyd54uq+qeX+gHBnxtN/y1fKOzGSnFJsIXuMXOZ3PpO3Lq8kEGAx5bSOGvjSuzl2EMQpMHyQzO4wr+4uyBY4SFI+aHUEeqErl3vKVy0NfFX8LrSm56MqI0hA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLiPlKOeQPDrwEt3jvEHwNxt0oPpH45UspjG5fFPE0o=; b=dgBIP2V+A63A2GB6NOo8NxauFYf1hPwIFBvVGSzfcPSXxbSZjxiJFyB3fWjTeM0ulJUN7FkBain6E2QjEHB7VpGCGKZNgWXAYxTEBSwaeWwPKOVY6WIxz76MafRUSK6poUb+p0pzbGIW4fus7Tipncmhp664wVfWibTMwT4oF3vTTPJLSTOH279IrtnHU1i15ALms047M/KbXoVb1jDYUTsdPygzVsRexUXqFHIj92Jug4XG10pZde7cCz7lsGa79j+UOb3e6O/o2GoUI4KncOkvDPj5MGzPn9NCcIyteLB1FPIKOCCA9HtBK2xccPPW+0OOn29I8cOW+l9UrxhcvQ== Received: from DB4PR03MB9531.eurprd03.prod.outlook.com (2603:10a6:10:3f4::19) by PA1PR03MB11020.eurprd03.prod.outlook.com (2603:10a6:102:4e1::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8943.30; Wed, 23 Jul 2025 12:22:47 +0000 Received: from DB4PR03MB9531.eurprd03.prod.outlook.com ([fe80::d437:a4b6:7558:ca14]) by DB4PR03MB9531.eurprd03.prod.outlook.com ([fe80::d437:a4b6:7558:ca14%5]) with mapi id 15.20.8943.029; Wed, 23 Jul 2025 12:22:47 +0000 From: Tom Barbette To: Stephen Hemminger , Scott Wasson CC: "users@dpdk.org" Subject: Re: rte_eth_dev_rss_reta_update() locking considerations? Thread-Topic: rte_eth_dev_rss_reta_update() locking considerations? Thread-Index: Adv1kPA9Nel+pfDRRNSyjP566DVuqwAQByaAAX55W2Y= Date: Wed, 23 Jul 2025 12:22:47 +0000 Message-ID: References: <20250715144015.7b2504d9@hermes.local> In-Reply-To: <20250715144015.7b2504d9@hermes.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-reactions: allow authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uclouvain.be; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB4PR03MB9531:EE_|PA1PR03MB11020:EE_ x-ms-office365-filtering-correlation-id: 4291677e-3c97-4df7-fd4f-08ddc9e3a25d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|1800799024|366016|7053199007|8096899003|13003099007|38070700018; x-microsoft-antispam-message-info: =?Windows-1252?Q?wL/lMpl726Rbf9+VMdcZGGGkan56B+1WCYOLoyQhDT1OfPW8wWlODY4M?= =?Windows-1252?Q?sAsKAfjYoP65Ga8zHXLp+J1WG+BFaavFGWqxTeS0dWOBzkBY7PyhO4T2?= =?Windows-1252?Q?dfFH7q8QcomsyPO+4P9gex2ko91x2Li1ySbVAMIZqz8LZoB7F5AZdruR?= =?Windows-1252?Q?PLrmqtmGhNypLcjQjlvaImzcW/dMBSs8habC9WPkHVeIm6CWXm0eFwjp?= =?Windows-1252?Q?Kig7CD2Njxvtd8yvzv5ThJ0FGmi3GAGkmrrapFp4N2z35J6+fx4m7MEo?= =?Windows-1252?Q?nVhyhp8UFcP9sxQiiZ4GAtDNon+y6SQbT3sdWvngSHon+M3kObYWtWSZ?= =?Windows-1252?Q?WTjzv+FeWL7UxDme6u9bI4yVSuGKMeXMLadWbc67CY6Zfsl1AOT1fh6q?= =?Windows-1252?Q?ykqzhibuaFUQe1M3hYPo3Ev+sqzRseLVMkWdWF6eQSfFqpD7iTCPOY7e?= =?Windows-1252?Q?MQhC5mtoJQ+D/aYpNK3RL9tEp6L2SrgUyw1vHEQMaEcZQxgNE5EMJz+9?= =?Windows-1252?Q?iI0NAG6kcoOc7ibu1WDrX6/7Z+I5JEDBsj06QZQxeO1B5QqU0+jy4hHz?= =?Windows-1252?Q?c6dibar0ev3IKje3pTfa9fd4lXIyzwn8zNwnJOdn2L5WAGv73VzP/pqJ?= =?Windows-1252?Q?QyXnvPnIkKkNLCn9x339ErUCqoo6eP+F3PjpZLPBPAjoT7LE57ScoWqR?= =?Windows-1252?Q?Ztew7a5rZRkSVizkRP77fEa6c+u4DNmLCj3KgZnUz0BsuquAIr+7HSrp?= =?Windows-1252?Q?krdbKGmKR594gN9p7Ya1kb0CH93s7gtcTfRPRNBd7gxnBMF9Qqv9jUOc?= =?Windows-1252?Q?/r/J0NiLritbOIfao5xuTaWgdSmsaJfeuUAk176oYhzOLw6oBKKa5vTX?= =?Windows-1252?Q?prkMzrbjrnP3jpCPeXdA9nvF3XDQfMT5eISsoKHm+s95kxfbPDcsJ+fe?= =?Windows-1252?Q?lCPYbAA97vuHnRKdSV7ESHYi9Y9ULp3eRXdcF72Wu//1UWxN0yHChSCL?= =?Windows-1252?Q?5gc23MFCd9Uzs7i0bFW53bjlzY274ZgKGSb1H4hvQGXkYb8KNgByJPwm?= =?Windows-1252?Q?MOuyTsHW/Axs4yy6GRY/LrXGQJQDpOtA18mzJ2Td37nRumYP/aC3PAJ6?= =?Windows-1252?Q?mDgSoBaeWhnbqtLvJxvJ21OJRltYanXzPLkqePbg85n+qvXX8sgTSUfy?= =?Windows-1252?Q?eAhSWAUfTv/MKqVDP8bGKnv0hsgoF8dkBZiuCMP7HbVWxD3ocd4v9LEy?= =?Windows-1252?Q?M2WnPlzZN9rtFHJuvURrQnJIBVnRnAis51OAHcG9vKVmwycBvGh2xJvf?= =?Windows-1252?Q?5cbvqBC+GwsGdsFkmxxF1yzxIBFRSAeqkgofo1UHGY7T5s5vKg1gAdPv?= =?Windows-1252?Q?UDDgWsXmVJ7xlIIl0E+4utEQ2YBHhK8PbnqggcpBRUQtMJoRt35RfC6i?= =?Windows-1252?Q?ux3l4gWBW/X3iAn3IVUW9KewgD9D0ltOFQC4QWaYstvDZBVc/9XcXJSK?= =?Windows-1252?Q?0chlAsQVzUBg09jROTTz0uI/pbdK4tyVyrM4BQoBg8C+mys4m2A=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB4PR03MB9531.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016)(7053199007)(8096899003)(13003099007)(38070700018); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?xq1bLZB5RgkboBMjNaloo80Zx+83pq6V+faucn5giZlSP8jWFtAXvNgd?= =?Windows-1252?Q?i9kQaEe/iAMlJdB4sWRqg+y7Hs/gFb9H7bwZp+oDIDN5P6MBQdc7QAAU?= =?Windows-1252?Q?8FC1cbCjIBIHaS9ivksCEA0wevRJy/1wYA6b6JjKVPSFHgoLmNosPTT1?= =?Windows-1252?Q?K+TtyENUK82c5FNFrUlPAVLrEu2480xpbyWzfOTcc1nmTCxrfXZUXxaf?= =?Windows-1252?Q?5hknJUaUJcLs4Fbn3jPAy+a7lyHRKwb6HKQslI722mAi+XLehDe8rkPo?= =?Windows-1252?Q?phNqe6aO6JDhVc9lpBBiwrk8KxmoosOv7zXUD1GvDDjcwB0+nrKWJobj?= =?Windows-1252?Q?Ug4ddVSpeepTZnkF3TZ9rcGYoaItGblb8Nyn5uUS38jcmW8bUFWduozz?= =?Windows-1252?Q?xzHnE1vQfo/Rxkcfj48LihQLeTVGzccQ+TphCnlrohm2ac4mnnb8wShH?= =?Windows-1252?Q?aQbslgk9veU4djWDiKiZrw/110af3e3fkvRHchhZLBqfvbEiVfMmBahr?= =?Windows-1252?Q?JnqxeVCx5aXugvZDZCspw5nKz6EkgNm7PnAO/zgDqKbuZltRKZpgFT8L?= =?Windows-1252?Q?Igrp3I/D9CpV+udaqwphFOH80afNRia8NaxixmXSQ7DgS1jN1kcPzgp3?= =?Windows-1252?Q?jhVeZsUhzoeOu5/6PcWa4elgLnJeky5LtYlhSm678GlvoTIVwuvlI/+e?= =?Windows-1252?Q?f++tJHjvP8cUHjYaXz90jSjO9hLpVv0rrhKJhS91KEfxy3qRpRjGS+Y+?= =?Windows-1252?Q?ibJCteTsGTerBNdVpWV+P1OfOhT4IP3HardYbpzt0YT5/oiF/r4ohRfe?= =?Windows-1252?Q?EBsk9jkYbRk3Z3RvhVwM75Pa3XrR2g9SSTExyE1ySqwAQKheHfn+sOMR?= =?Windows-1252?Q?wmyagvJLGV95zb6b0CsorWqzr6CTBi8PKYQ+ev/CI+dN+zFHhZ0b/Rip?= =?Windows-1252?Q?y2kI2RmqwzARfGm3ySZ0pLnQ2gGIJOAZ75+rW2DlnrhwZIOE6dB+KQ8B?= =?Windows-1252?Q?189pRFUrPxBrGZZbDfulSzHj/FulUICXQcUiaKnm3scU0Ju1pgGw2UDa?= =?Windows-1252?Q?9TmTVz5r/fBa/s3ERfqzgcN+7J7efDDlSRwYBT86oYP3Sp0D9FPUnf1T?= =?Windows-1252?Q?cZzlkdaoVndUk4fURvKLxq+SpAbOx8VOtfW6Me0yV+vbeTydwEjWHRSs?= =?Windows-1252?Q?m5eA+CV0/5Lv5LQttTBQat2LcX1C/vwqATRT1xSeM3gK5KhlZGJPMS3n?= =?Windows-1252?Q?IF27L2R+VMJJa8Aoj/LQLVqZCeM0qekBUSXNvKv7u417wAiV/7SDbP1E?= =?Windows-1252?Q?SNqeZ6INPCwE1+T3j2mkWJVkZZ3oeTpF7MewqhjAxFpiIfyVALdkonAJ?= =?Windows-1252?Q?XkVePmZhMgVvMBN83VXxv5eFs3qdjfHYjRI//zAiCVqoPhVNH42iqwli?= =?Windows-1252?Q?+OWIwzGwXl0IDcpniorRnXO0bTMI6MPEUBuyouEaLRWPeZsTLUV8yO0v?= =?Windows-1252?Q?VGHmk3F6qIfX0jI+6nIDuDhj8+ZFy+ONDsibdbfQj5tXAkkONYg1DA9L?= =?Windows-1252?Q?9IGwIhIrM8J+a/zr0MLFDv9EupMvLTn9LHzDDJDsCq8lkEkaLs3jIwPG?= =?Windows-1252?Q?c7dL/pNXJCuX3ucRYWPwep/A75M5s4m4D8VtkdEb8J+bWCm6Mw+Q35or?= =?Windows-1252?Q?TmtjqZxt7dL8+M8qF8n639EWzQo/exi7r+aAllRKpUn8WOx8UuEgvg?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DB4PR03MB9531E13456A984B073FC7B73E85FADB4PR03MB9531eurp_" MIME-Version: 1.0 X-OriginatorOrg: uclouvain.be X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB4PR03MB9531.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4291677e-3c97-4df7-fd4f-08ddc9e3a25d X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2025 12:22:47.5131 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RdXadkKrhZ1iJBhRrBsX0XDQkkD8i0/TRJ8TRwcqo6sQX8FRk8FD1/mJRBr65JY5+cz3O0XBjTOonIH0YgySiOMbksic2fEsgYOe2fc2Rno= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB11020 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_DB4PR03MB9531E13456A984B073FC7B73E85FADB4PR03MB9531eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, As Ivan mentioned, this is exactly what we did in RSS++. For the concern about RSS reprogramming in =AB live =BB, it depends on the = NIC. I remember the Intel card we used could use the =93global=94 API just = fine. For the Mellanox cards we had to use the rte_flow RSS action as repro= gramming the global RETA table would lead to a (partial ?) device restart a= nd would lead to the loss of many packets. We had to play with priority and= prefixes, but rte_flow and mlx5 support has evolved since then, it might be a bit simpler= , just using priorities and groups maybe. The biggest challenge was the state, as written in the paper. We ended up w= ith using the rte_flow rules anyway so we can use an epoch =93mark=94 actio= n that marks the version of the distribution table and allow an efficient p= assing of the state of flows going from one core to another. The code of RSS++ is still coupled a bit to FastClick, but it was mostly se= parated already here : https://github.com/tbarbette/fastclick/tree/main/ven= dor/nicscheduler We also had a version for the Linux Kernel with XDP for counting. We can chat about that if you want. NB : my address has changed, I=92m not at kth anymore. Cheers, Tom De : Stephen Hemminger Date : mardi, 15 juillet 2025 =E0 23:40 =C0 : Scott Wasson Cc : users@dpdk.org Objet : Re: rte_eth_dev_rss_reta_update() locking considerations? On Tue, 15 Jul 2025 16:15:22 +0000 Scott Wasson wrote: > Hi, > > We're using multiqueue, and RSS doesn't always balance the load very well= . I had a clever idea to periodically measure the load distribution (cpu l= oad on the IO cores) in the background pthread, and use rte_eth_dev_rss_re= ta_update() to adjust the redirection table dynamically if the imbalance ex= ceeds a given threshold. In practice it seems to work nicely. But I'm co= ncerned about: > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdoc.d= pdk.org%2Fapi%2Frte__ethdev_8h.html%23a3c1540852c9cf1e576a883902c2e310d&dat= a=3D05%7C02%7Ctom.barbette%40uclouvain.be%7Cebeee334aef74a19446308ddc3e8354= 5%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C1%7C0%7C638882124267510617%7CUnknown= %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs= IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DBopyVlMOW0CGCdLDk9Q%2= BLf87r81NOzCG%2Bv4w4rMezDI%3D&reserved=3D0 > > Which states: > > By default, all the functions of the Ethernet Device API exported by a PM= D are lock-free functions which assume to not be invoked in parallel on dif= ferent logical cores to work on the same target object. For instance, the r= eceive function of a PMD cannot be invoked in parallel on two logical cores= to poll the same Rx queue [of the same port]. Of course, this function can= be invoked in parallel by different logical cores on different Rx queues. = It is the responsibility of the upper level application to enforce this rul= e. > > In this context, what is the "target object"? The queue_id of the port? = Or the port itself? Would I need to add port-level spinlocks around every= invocation of rte_eth_dev_*()? That's a hard no, it would destroy perform= ance. > > Alternatively, if I were to periodically call rte_eth_dev_rss_reta_update= () from the IO cores instead of the background core, as the above paragraph= suggests, that doesn't seem correct either. The function takes a reta_con= f[] array that affects all RETA entries for that port and maps them to a qu= eue_id. Is it safe to remap RETA entries for a given port on one IO core w= hile another IO core is potentially reading from its rx queue for that same= port? That problem seems not much different from remapping in the backgro= und core as I am now. > > I'm starting to suspect this function was intended to be initialized once= on startup before rte_eth_dev_start(), and/or the ports must be stopped be= fore calling it. If that's the case, then I'll call this idea too clever b= y half and give it up now. > > Thanks in advance for your help! > > -Scott > There is no locking in driver path for control. It is expected that application will manage access to control path (RSS bei= ng one example) so that only one thread modifies the PMD. --_000_DB4PR03MB9531E13456A984B073FC7B73E85FADB4PR03MB9531eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi all,=

&n= bsp;

As Ivan= mentioned, this is exactly what we did in RSS++.

&n= bsp;

For the= concern about RSS reprogramming in =AB live =BB, it depends on t= he NIC. I remember the Intel card we used could use the =93global=94 API ju= st fine. For the Mellanox cards we had to use the rte_flow RSS action as reprogramming the global RETA table would lead to a (partial=  ?) device restart and would lead to the loss of many packets. We had to play with priority and pr= efixes, but

rte_flow and mlx5 s= upport has evolved since then, it might be a bit simpler, just using priori= ties and groups maybe.

 

The big= gest challenge was the state, as written in the paper. We ended up with usi= ng the rte_flow rules anyway so we can use an epoch =93mark=94 action that = marks the version of the distribution table and allow an efficient passing of the state of flows going from one core t= o another.

The cod= e of RSS++ is still coupled a bit to FastClick, but it was mostly separated= already here : https://github.com/tbarbette/fastclick/tree/main/vendor/nicscheduler<= /a>

We also= had a version for the Linux Kernel with XDP for counting.

&n= bsp;

We can = chat about that if you want.

&n= bsp;

NB = ;: my address has changed, I=92m not at kth anymore.

&n= bsp;

Cheers,=

Tom

&n= bsp;

 

De : Stephen= Hemminger <stephen@networkplumber.org>
Date : mardi, 15 juillet 2025 =E0 23:40
=C0 : Scott Wasson <swasson@microsoft.com>
Cc : users@dpdk.org <users@dpdk.org>
Objet : Re: rte_eth_dev_rss_reta_update() locking consideration= s?

On Tue,= 15 Jul 2025 16:15:22 +0000
Scott Wasson <swasson@microsoft.com> wrote:

> Hi,
>
> We're using multiqueue, and RSS doesn't always balance the load very w= ell.  I had a clever idea to periodically measure the load distributio= n (cpu load on the IO cores)  in the background pthread, and use rte_e= th_dev_rss_reta_update() to adjust the redirection table dynamically if the imbalance exceeds a given threshold.  In pra= ctice it seems to work nicely.   But I'm concerned about:
>
> ht= tps://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdoc.dpdk.= org%2Fapi%2Frte__ethdev_8h.html%23a3c1540852c9cf1e576a883902c2e310d&dat= a=3D05%7C02%7Ctom.barbette%40uclouvain.be%7Cebeee334aef74a19446308ddc3e8354= 5%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C1%7C0%7C638882124267510617%7CUnknown= %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs= IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DBopyVlMOW0CGCdLDk= 9Q%2BLf87r81NOzCG%2Bv4w4rMezDI%3D&reserved=3D0
>
> Which states:
>
> By default, all the functions of the Ethernet Device API exported by a= PMD are lock-free functions which assume to not be invoked in parallel on = different logical cores to work on the same target object. For instance, th= e receive function of a PMD cannot be invoked in parallel on two logical cores to poll the same Rx queue [of = the same port]. Of course, this function can be inv= oked in parallel by different logical cores on different Rx queues. It is t= he responsibility of the upper level application to enforce this rule.
>
> In this context, what is the "target object"?  The queu= e_id of the port?  Or the port itself?  Would I need to add port-= level spinlocks around every invocation of rte_eth_dev_*()?  That's a = hard no, it would destroy performance.
>
> Alternatively, if I were to periodically call rte_eth_dev_rss_reta_upd= ate() from the IO cores instead of the background core, as the above paragr= aph suggests, that doesn't seem correct either.  The function takes a reta_conf[] ar= ray that affects all RETA entries for that port and maps them to a queue_id= .  Is it safe to remap RETA entries for a given port on one IO core wh= ile another IO core is potentially reading from its rx queue for that same port?  That problem seems not much different from remapping = in the background core as I am now.
>
> I'm starting to suspect this function was intended to be initialized o= nce on startup before rte_eth_dev_start(), and/or the ports must be stopped= before calling it.  If that's the case, then I'll call this idea too = clever by half and give it up now.
>
> Thanks in advance for your help!
>
> -Scott
>

There is no locking in driver path for control.
It is expected that application will manage access to control path (RSS bei= ng one example)
so that only one thread modifies the PMD.

--_000_DB4PR03MB9531E13456A984B073FC7B73E85FADB4PR03MB9531eurp_--