> -----Original Message----- > From: Stephen Hemminger <step...@networkplumber.org> > Sent: Tuesday, October 22, 2024 17:41 > To: Dariusz Sosnowski <dsosnow...@nvidia.com> > Cc: Slava Ovsiienko <viachesl...@nvidia.com>; Bing Zhao <bi...@nvidia.com>; > Ori Kam <or...@nvidia.com>; Suanming Mou <suanmi...@nvidia.com>; Matan > Azrad <ma...@nvidia.com>; dev@dpdk.org > Subject: Re: [PATCH v2 00/10] net/mlx5: improve MAC address and VLAN add > latency > > On Tue, 22 Oct 2024 14:06:08 +0200 > Dariusz Sosnowski <dsosnow...@nvidia.com> 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.
I could not find any existing functional test in DPDK or DTS for such a scenario.
