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 4C4F945BA3; Tue, 22 Oct 2024 17:41:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 38F37402C2; Tue, 22 Oct 2024 17:41:06 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id CE1074029B for ; Tue, 22 Oct 2024 17:41:05 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-20ca388d242so41152845ad.2 for ; Tue, 22 Oct 2024 08:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1729611665; x=1730216465; 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=h5TpN4kJmvU6CFyI2FFuDPfPmSxJWWsSlvsu4eL2cRA=; b=kUZH7vJKkCk28YRz+ordVTlLpNYmImeibu7avfaIwfwviPhy7eB2t7z69SsjZJwa8X QChy3nSvhXyQ8uesf1rX2BiAkNuCU5wfh/Zn1H2fiIdGSHEGpe55DS9Cd9m5AWglFCf1 uDseQoowVxlaA4BrDDBiLUBuyg6+rTETd15j7Z82l28T4h7TC3FbPjANOS9F6OdnQdWp VC7Q918EneRV+9x6ek1BvF5Xzcc7s/NONDaGIbWvctcRdjVVU8m7mlur36EUg7QuwVdX M+C7sVqkoKQ/DPjehX9LSoCH13DHdFUtRVstU/tRomEWHmY4kONw1csUEcV+HiZtrs8y rSOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729611665; x=1730216465; 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=h5TpN4kJmvU6CFyI2FFuDPfPmSxJWWsSlvsu4eL2cRA=; b=pKdjuHy/VlMubFB4rL4f4y2OeHphjhTiEhC+3WkpAUu0vYDn9JP6yVWbsPpEjId5Re z10x83ZWIrM/AcD5gexEYpwE9XOIccvcIMk9uPtyt7Q2jjQaoiSQHT56LKFyrNTN7dtZ 16joea3+asxAJIg968EtJNRJuT9HndU0cezFwubkpYg2qzRGijEeHFmmeteOkipeBDkP K7lSQKrvV9+HveA0pCuS1R3BWjL4ar08tkRlGKjdVpd9bMpq0Jo4uomwqcf1QzTFxjLA ltgMOUM0i3IawO2qCx16GzLh96fgk1gJps/yLV3cQKsdJkF/uE1aY52YRIfa/tY2Qhjf Q7RQ== X-Forwarded-Encrypted: i=1; AJvYcCVY5Q94Uh3q8KGfNphwzsnFaR5mkGKtd+pEt/NM0I6yOtdqSal+oSflnefq6GRKA63zqn8=@dpdk.org X-Gm-Message-State: AOJu0YxuMHXwRXZZALSQqJwbxbtlBtWiDajNBtqiyTA+XR1TlSgpbbou ULB33gc18Gslg+1J/DiQldlaRp7abVWugnFMpWPy4F3QtihZDFwpK6F09ciIR9U= X-Google-Smtp-Source: AGHT+IFnRUKN1mGKwGKCmucWYG5g0xLH/idbH7JijpQ8435PN8G2oKzHKkqm4+lIkjOmOqr1DcjfIw== X-Received: by 2002:a17:902:f686:b0:20c:637e:b28 with SMTP id d9443c01a7336-20e5a944216mr170640865ad.39.1729611664950; Tue, 22 Oct 2024 08:41:04 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20e7ef1330csm44259595ad.86.2024.10.22.08.41.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2024 08:41:04 -0700 (PDT) Date: Tue, 22 Oct 2024 08:41:03 -0700 From: Stephen Hemminger To: Dariusz Sosnowski Cc: Viacheslav Ovsiienko , Bing Zhao , Ori Kam , Suanming Mou , Matan Azrad , Subject: Re: [PATCH v2 00/10] net/mlx5: improve MAC address and VLAN add latency Message-ID: <20241022084103.5c89b9a6@hermes.local> In-Reply-To: <20241022120618.512091-1-dsosnowski@nvidia.com> References: <20241017075738.190064-1-dsosnowski@nvidia.com> <20241022120618.512091-1-dsosnowski@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 22 Oct 2024 14:06:08 +0200 Dariusz Sosnowski wrote: > Whenever a new MAC address is added to the port, mlx5 PMD will: > > - Add this address to `dev->data->mac_addrs[]`. > - Destroy all control flow rules. > - Recreate all control flow rules. > > Similar logic is also implemented for VLAN filters. > > Because of such logic, the latency of adding the new MAC address > (i.e., latency of `rte_eth_dev_mac_addr_add()` function call) > is actually linear to number of MAC addresses already configured. > Since each operation of creating/destroying a control flow rule, > involves an `ioctl()` syscall, on some setups the latency of adding > a single MAC address can reach ~100ms, when port is operating with >= 100 MAC addresses. > The same problem exists for VLAN filters (and even compounded by it). > > This patchset aims to resolve these issues, > by reworking how mlx5 PMD handles adding/removing MAC addresses and VLAN filters. > Instead of recreating all control flow rules, > only necessary flow rules will be created/removed on each operation, > thus minimizing number of syscalls triggered. Looks good. Is there already functional test which does this? Mlx5 may not be alone in having this problem.