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 9333A46B81 for ; Tue, 15 Jul 2025 18:15:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 31FCD402DC; Tue, 15 Jul 2025 18:15:28 +0200 (CEST) Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazon11022115.outbound.protection.outlook.com [52.101.43.115]) by mails.dpdk.org (Postfix) with ESMTP id 04BFE4028C for ; Tue, 15 Jul 2025 18:15:26 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JB7B78CtepMRyMdoJThAPR0rmr5Mn37l9VCaww/9/ovUKWRHr5RaJl9ZQ+lgEJu3xWmVKZuJGgpbBuj6V3Sh/UUQ5zn2bIZBEE4GjRZV6uTNuksHTt0FQoa0Sn3NQPtYDULvZdZx9/+7sn5bh2RbzZXRDg6UasKnvGheRlNEb6Jk4p2Aah9hutFueYjlU4i1/lweV8egbwKaYogrK83MrmZ2/j6XlBZ6waDd7RiAvJ2CqGQzyvsBeOsT4obF6VQaJSagdd+WF2dfH/R2W3mpIX+fmNPzofxhfJht1wlPtrHS5sTpEMRJ5jPUNNYkGjTLR7Q6xS4PB/7kzkyjk27ehw== 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=B64KPu/nwjEf2Vo20MHkmgUc2ZJ++3fNYea2slB73ds=; b=XMFxKzVyFXLNBcXRPSeJHytwquNHiICg9VtUbkDTlOTG1DVY8CwaW8hByZWRx34f8DyHJtWoAFA0rCS2DoLIYVapvATZyNuW7ST6e46O3WTeyO3p9SDeY5WPa4d0s/qWNQD3Qdls/AztBJbp/k3NbrSZOE83EUDCR44KTvRfKbyBalpi2sBlpuW2ep1BCyb58GE3g9hcnr7u4R4owLURKpMtsrpo2bESxQaOaBnPb0VhcQCqfIowMildw8mToczcC21BLnKblBvFvfof/REFRbTsHBcJJ3Z3eKSbCaU3WYeWHaJEHUTHvWNBzKIQli8YnBO8ik/La1Ofrbwp4W9mTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B64KPu/nwjEf2Vo20MHkmgUc2ZJ++3fNYea2slB73ds=; b=FHhpn9YpdEgqBx+wiDKfh+XQcfZcmQpM8rFlzOMTcwF8VLlbY+ahckt5tYNNgAyfuKL97YeQZzhS0vRhZqJ6TpmuED2COyDsVKL/R98YnBe/ddfojNSeNRsKlcWUXvBZkRCKRMoLE0IbFNgexJlOfj8hCUhsTZ7e8irB9pgDVJQ= Received: from LV9PR21MB5524.namprd21.prod.outlook.com (2603:10b6:408:2ec::11) by LV5PR21MB4729.namprd21.prod.outlook.com (2603:10b6:408:303::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8922.12; Tue, 15 Jul 2025 16:15:22 +0000 Received: from LV9PR21MB5524.namprd21.prod.outlook.com ([fe80::415:d00b:a8b:f14f]) by LV9PR21MB5524.namprd21.prod.outlook.com ([fe80::415:d00b:a8b:f14f%6]) with mapi id 15.20.8964.007; Tue, 15 Jul 2025 16:15:22 +0000 From: Scott Wasson To: "users@dpdk.org" Subject: rte_eth_dev_rss_reta_update() locking considerations? Thread-Topic: rte_eth_dev_rss_reta_update() locking considerations? Thread-Index: Adv1kPA9Nel+pfDRRNSyjP566DVuqw== Date: Tue, 15 Jul 2025 16:15:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e32a9e9b-c8e8-4ca1-9309-ccccf2bba444; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2025-07-15T14:00:11Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Tag=10, 3, 0, 1; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: LV9PR21MB5524:EE_|LV5PR21MB4729:EE_ x-ms-office365-filtering-correlation-id: 0a61001d-3592-4594-74af-08ddc3baccc7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|366016|376014|13003099007|8096899003|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?Q3K5iJPBEj63CND9y9fTXJH+yWJNP6VYHzy7z0H0jBzM23vMkAabwYxAruRc?= =?us-ascii?Q?mJVJlzNREVPO0tnc5edZOB45XSi1MryL7cbfrHgs9lGsnOsC8kd7k4zGgdrm?= =?us-ascii?Q?VJSWuIQTn6XlhAngwgMYCbWPmz2PbB5na0NHGiEQKP3fPH8ncrXm2NNz6uhq?= =?us-ascii?Q?QKxmLmWB60EtBna8FYNVjnNw7OJFyEWpENxsUkjuwQU+8Lqp0MWYWufrEG27?= =?us-ascii?Q?2AnUBA9x0ylrYaV5IAZCX0XeLwawxDOV4hIUD4/xXlp8wScAxr+QW6Tcz6aV?= =?us-ascii?Q?qizn8Q16RFlJ9h3Z1Zu7TtMUOLI/EY8RHmZ3jipiS7g9c9QYlK13TfhLXKSr?= =?us-ascii?Q?7pWuouZSmi9jtdGOs8hC+UpF1XtUwiu9EcPFT5APgtnzaAdGS9o8iKtksmbp?= =?us-ascii?Q?SGU4c3DLsKUYSGjtavbN0GPAGbQi/l1nddT2upEx10lrhnd4uKSmmDxDnAuX?= =?us-ascii?Q?XdZMixDStYuRqchR90MVrCX+pSSCBPpC7DgdJrB4FXjY7PWSCiJ3l2XzmT1f?= =?us-ascii?Q?CTD309RO1B201lx3FarJb6Xd04ED664kXUyx6r19130ZPOYdP4GmsdGOM0a7?= =?us-ascii?Q?DHhSteAp2t8XPpNGwqDGwzCX5ndIhf30lrnjrFl3gkSzViUhCa1pflzNTath?= =?us-ascii?Q?JjiBa9/1vko5CkH6IeWGqdsGT8sjCDvUt++GMA9p/W0doUD4PvDQjrFcpx1Y?= =?us-ascii?Q?jJHAonhzrOBDNK8c/AuRWV2p9NxA86PDWY7u+3XTF13DaNZG0gLaNYhbPDOM?= =?us-ascii?Q?TwmkLv1q9IKxLt7Kjc1X33rORezmO9i+a/krO9oLv8r5fjduv15ygyxoYUV+?= =?us-ascii?Q?88c41P037fwHvZfxuneU35NlRzQ/0PXOisrZ5hVmkvcomEtoBUEWx9d4yV1b?= =?us-ascii?Q?JWsDGywu7N95ThvBio2HLIaMl+Rilw3b4662oOd9e96/b/c/9bAXobRNUZCs?= =?us-ascii?Q?DnfxAkUZUIt6utwrSna4QiJwJ0PJJmV9m76bKUe310tXrqY0KRa3HBlFiqFD?= =?us-ascii?Q?3mnfqennlT3GSHNB3tvrI3vCZea+dMwa/LLGoqujSURugjugXmp9QwMYChqe?= =?us-ascii?Q?zHRuHRcUwjxrqs+0B3YVUhPARhPlEgPIAtUE724et3AgKu9zNzyCj/daS1I/?= =?us-ascii?Q?HVJb7Ll4CS6802q13EamwZALpZYWoBjTn2zmdNOl6ty0VRYUSLWnKk135UbV?= =?us-ascii?Q?4Dv93cSLMnHGa26O3Aw+DUrIpRrGLiBmskcs9GEqhHicNkiHV0vtRcUzyDzX?= =?us-ascii?Q?zbT/AQnwqbKEVGe3A5PPkeeCMCuUnVvwNx48M7HvFLIGA819Gm29GtMMLP5t?= =?us-ascii?Q?te7qZ6ABZABMBD9RJJ9SHbDEHCuzWGpxRVDQph5k6U2qdJPCxUaDcgslvkKO?= =?us-ascii?Q?5WBNSOVfxjX5hxYXpaWVlaGYBSy7Hy4/F9taNG8KhwxFdCbEQTtADrH9/arE?= =?us-ascii?Q?Y5y79VfO9b4=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LV9PR21MB5524.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014)(13003099007)(8096899003)(38070700018); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?UeyJ6MnUjHFEuAnA1L0R0CmG2t5blBJXzbFTEmkRi+ecPn7RUeP9QC02XOw2?= =?us-ascii?Q?+ppp3uNClt5wAMSrGu+nbD0Hfrqzkj3+11FnzztgF47yarMwkT1XQlmK2TwS?= =?us-ascii?Q?JtbAj94weEfkjp12pXoCuiw6yT3Wv3pd7MCkRU52z95qUaWezRRFjK4Yiaj8?= =?us-ascii?Q?I+tco4coYSrpQ4LLTBBBjBZsAZ7Q1hgP4g/Z2XHn/ZOrD3XrYkufA7Ttg1Kn?= =?us-ascii?Q?/37zn9DDcHB25k34vIQM/9xwP5brvekJx/3NV9v8yPyqcrr+ONJOu+IlMOts?= =?us-ascii?Q?ijhvjboY9UNutfi9t7loQxJ8Xb2p56UOt9QWjfcYDDmzgwpTGLKSeVc8u222?= =?us-ascii?Q?8NzDg7veN7ZhlXdooDVVTwwRlda7rcj6/hRsdMxG8yNLh238l4Jau/8jnJob?= =?us-ascii?Q?hl8zqehHoW19qXN3dblkCj7Ircm8yk0UXWWagLzDfe0rwI8y5iKdDdhiTssQ?= =?us-ascii?Q?LiZ+4b+zTQH6/Ya3Uizgd22EmpQa77YdoKLxsY9WtC+uA7VIlLGvZS4/aw6Z?= =?us-ascii?Q?7gxz/hVp9GbhRQU8xl4KbVGzEyLqQoZWyD42TegcyVv6e+tnCMaHtov/0HZ4?= =?us-ascii?Q?q4WVUPS3bOXv1KVqVua1fPxiW/PoT0Ocf+yi25Ajbpjc8Omr/QPi7upiBYrM?= =?us-ascii?Q?m+3uik5QX3OQYWtai0DwDNQHQ50ed6lesqxgWKUrapu2eOOsK/lsrvAAwYM8?= =?us-ascii?Q?hQqwA+dUIAzaWbnVLkFfSRhATGD07vkw01Z7nWviRKgumKQRTJhy4WBDlfk6?= =?us-ascii?Q?znrzl8pOjXNMuvmSkXHczizzbriPHcbnxowrwog8sEpSVAQQs0OMuu9TwODQ?= =?us-ascii?Q?vm2HqV8KaB0q+VYPOvFgh+zliAX81BdsU8VVwuVhqBQveFq73q63VQdr3LMT?= =?us-ascii?Q?Vk6jHQ6m6oymxnX9gt1P3xQ/UpmtYcHBXD9pDVTwiEnqAOdHu/G58X6UpKfI?= =?us-ascii?Q?Ixi/yw+vuBNK8qNbTWMBn3BgDQ0+Hoe4oEb/3NU5DD42viOoa8Kl5KIgMpZF?= =?us-ascii?Q?c9hBuWRJTFFsDopJy6ulu1Gy42nRezyC6BUBYNiV87Z9bvD31ARvDqUn4GQ3?= =?us-ascii?Q?NWiyRg+nip2zRKhDJHNO+wvxcaK8a8BuhawSPyHqckwseqDe5SV1ggjzjZ7r?= =?us-ascii?Q?HRMK7r0H1VALGV/yIxUm0E7K2UStEZzDl3gIbZ36eQskBJV5rcIa6NAYqCck?= =?us-ascii?Q?WxXgA7076Gcm+Zo2tag399lXJgfzqIjSuAMyyHLNTHlLD9bV59tchcTq2VyM?= =?us-ascii?Q?J6eT8njg02hRpi75fnOj2ycrU3JpwslOGewfAzgXm3Z+bizr+uNLkNfjmzQa?= =?us-ascii?Q?KdEXQQhxdB99bhNvWKQuSwQUPs7uM4pL1XEogfZ1yM2Gzg3AddJHI6i1MO9w?= =?us-ascii?Q?klUclgbkRBb++OFiv5o8G24ndm5MwQLuES61g+RmXKfL0S3XMFelVgnjxFIz?= =?us-ascii?Q?e1vu8tEcGTiSzAL2sotUn5rfRQwprPIS1w2i5VZ5jE7iOme+A16I0Lst6Yus?= =?us-ascii?Q?aVrPgGntB9WeTMuAdHda3es2Yb4301krPseJ?= Content-Type: multipart/alternative; boundary="_000_LV9PR21MB552466FAAE0DCD47714322AFA557ALV9PR21MB5524namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV9PR21MB5524.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a61001d-3592-4594-74af-08ddc3baccc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2025 16:15:22.3273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 63wI3hy2tL+oNcqRLshUzyHydJqMbYbvXt+9xodM3cSqW325+AIb0OHbAGTgOLZKqnJ584iTZq28f7Zr7+k9Dw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR21MB4729 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_LV9PR21MB552466FAAE0DCD47714322AFA557ALV9PR21MB5524namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 loa= d on the IO cores) in the background pthread, and use rte_eth_dev_rss_reta= _update() to adjust the redirection table dynamically if the imbalance exce= eds a given threshold. In practice it seems to work nicely. But I'm conc= erned about: https://doc.dpdk.org/api/rte__ethdev_8h.html#a3c1540852c9cf1e576a883902c2e3= 10d 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 diffe= rent logical cores to work on the same target object. For instance, the rec= eive function of a PMD cannot be invoked in parallel on two logical cores t= o poll the same Rx queue [of the same port]. Of course, this function can b= e invoked in parallel by different logical cores on different Rx queues. It= is the responsibility of the upper level application to enforce this rule. In this context, what is the "target object"? The queue_id of the port? O= r the port itself? Would I need to add port-level spinlocks around every i= nvocation of rte_eth_dev_*()? That's a hard no, it would destroy performan= ce. 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 s= uggests, that doesn't seem correct either. The function takes a reta_conf[= ] array that affects all RETA entries for that port and maps them to a queu= e_id. Is it safe to remap RETA entries for a given port on one IO core whi= le another IO core is potentially reading from its rx queue for that same p= ort? That problem seems not much different from remapping in the backgroun= d core as I am now. I'm starting to suspect this function was intended to be initialized once o= n startup before rte_eth_dev_start(), and/or the ports must be stopped befo= re 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 --_000_LV9PR21MB552466FAAE0DCD47714322AFA557ALV9PR21MB5524namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’re using m= ultiqueue, and RSS doesn’t always balance the load very well.  I= had a clever idea to periodically measure the load distribution (cpu load = on the IO cores)  in the background pthread, and use rte_eth_dev_rss_reta_update() to adjust the redirection table dynamically = if the imbalance exceeds a given threshold.  In practice it seems to w= ork nicely.   But I’m concerned about:

https://doc.dpdk.org/api/rte__ethdev_8h.h= tml#a3c1540852c9cf1e576a883902c2e310d 

Which states:<= /o:p>


By default, all the functions of th= e Ethernet Device API exported by a PMD are lock-free functions which assum= e to not be invoked in parallel on different logical cores to work on the s= ame target object. For instance, the receive function of a PMD cannot be invoked in parallel on two logical cor= es to poll the same Rx queue [of the same port]. Of course, this function c= an be invoked in parallel by different logical cores on different Rx queues= . It is the responsibility of the upper level application to enforce this rule.

 

In this context, wh= at 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 woul= d destroy performance.

 

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 suggest= s, that doesn’t seem correct either.  The function takes a reta_= conf[] array that affects all RETA entries for that port and maps them to a queue_id.  Is it safe to remap RETA entr= ies for a given port on one IO core while another IO core is potentially re= ading from its rx queue for that same port?  That problem seems not mu= ch different from remapping in the background core as I am now.

 

I’m starting = to suspect this function was intended to be initialized once on startup bef= ore 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 f= or your help!

 

-Scott

 

--_000_LV9PR21MB552466FAAE0DCD47714322AFA557ALV9PR21MB5524namp_--