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 D3A5A46B82 for ; Tue, 15 Jul 2025 23:40:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 77DAB4021E; Tue, 15 Jul 2025 23:40:20 +0200 (CEST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id AE6274013F for ; Tue, 15 Jul 2025 23:40:18 +0200 (CEST) Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-234f17910d8so59669495ad.3 for ; Tue, 15 Jul 2025 14:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1752615617; x=1753220417; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=un5hE5o7GtL7c8ueDXp3akFVY+OchkttVgvsn7NMGjE=; b=S67tbTaMIWAqpeEZ1v4dbX2s1cpLNd/fUWnWDcSKDMHJNqZo5A0LOgjaM9u6t0v+YB 4udokUi5umHnaPOL10yKWnecKyYn7/uZuMRapOp747kDA0lCAEORi0WvzQ35d9KF2eiq 3IY9/fJKS69ro1eSPLJ7P3k8p51D1zy9r9skcETtM0ic0u/Q0WHgt3ItuK96tzktv1Kh GdcXFo/PxbfiWiRk/lK3iVxXaiG/Px+wRjTkeMJkHKaCe6151GjTsgM/m6wEivbJ3o5p 51aIf+ocJ/peOv4P7xyVbBK0vVbsyjTAD6t9DYUNHycxV9Fb0C25XsxWfIJQ6RPtrQy5 y4Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752615617; x=1753220417; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=un5hE5o7GtL7c8ueDXp3akFVY+OchkttVgvsn7NMGjE=; b=XftdyhESJgyj5MbodPK9eAtn6ejFLpY+AcfpXGaRFmT5QEGmlI2UjnSF1zto+ZNsgt iNJjeg3cUKWI6UT9lHDVbpwofD4DpHJuxKQpKJluOW6E8HtF7ZcSNBpYYj6HYWufIezc VmVUVv9RSlzPAfTvSH4qxMzAUn8zE9fCoydg/3iOHzv4ziEZUZxYfnql8Z0abYc8qNnq 5xwq6hhuau/OBzNurDrkNG/kAggxb1NBVYVf0/eYOnkDOBm0Gh3UEywl12OAaiAaWtmu 3YRVJp4ir7LVjZ1DH6RufSY0EFmPN/Qjf3bUTCpEXsrDByGmH1d18KyO/pP1M4eMQDgZ 9qVw== X-Gm-Message-State: AOJu0YwCXHnT9GqXHbp+2w1sesdKHJKQWBHmFf58pAuIGJ81Av9z/+mT rasULvwauMYQmkcP2azXGjOPQuSjcof/XR0xVeHHTTSP/+EJfdYVZVHwLf8m80jWHdc= X-Gm-Gg: ASbGnctUAwsb7Nx3TUfzMMR5I4zuzdZyLqQAd96NTnRsYFa25AV53rBQkilB3mH+Jzr v60T5jY0hnO7532WZ3QfLvJdpgNsIEWQ9MLkiCK8/dvOa+ofiU6wm6H8rcBCRdgPGx0iZin3fA1 PKZ1GS74Risk5J82kqDrpWYQwZdNq6+M0vgbbMF0ug4//pORIfubxpHldNJKo3miAoRKG5V2sM9 XjziXfoMqOJPUn4YplChijv3ZDBmxoWcT7wOjWurQtcPJFTqwH9TGG9t5mur+Q/TrnECrFIyCZz XLJTKSEtKHlI4SUHIxlwJ/iG3DJmla0OqOZeyAZZgsdbxOfvB32R+U+Fc3pPo59RJPwDP1cng9q 764xOHkxdw6cG8tDFMCbUF0YmcJkocht4J2JeJOJzkDMdqOQPUAJoAvg5D4ftYllYyOMY/8vPux A= X-Google-Smtp-Source: AGHT+IGyrcTNn9NfbO1IfXGoxxayfvQOOz3CyRTejiN/5Z6hQTrpEa38ynPv5NYE3DlSUL6ya2vTFg== X-Received: by 2002:a17:903:3bc6:b0:234:9068:ed99 with SMTP id d9443c01a7336-23e24f44f05mr10941275ad.24.1752615617504; Tue, 15 Jul 2025 14:40:17 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23de42845c7sm114298985ad.26.2025.07.15.14.40.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jul 2025 14:40:17 -0700 (PDT) Date: Tue, 15 Jul 2025 14:40:15 -0700 From: Stephen Hemminger To: Scott Wasson Cc: "users@dpdk.org" Subject: Re: rte_eth_dev_rss_reta_update() locking considerations? Message-ID: <20250715144015.7b2504d9@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 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 work nicely. But I'm concerned about: > > https://doc.dpdk.org/api/rte__ethdev_8h.html#a3c1540852c9cf1e576a883902c2e310d > > 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, the 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 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? 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_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_conf[] array 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 while 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 once 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 being one example) so that only one thread modifies the PMD.