[PATCH v2 00/10] net/mlx5: improve MAC address and VLAN add latency

[Dariusz Sosnowski]

> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Tuesday, October 22, 2024 17:41
> To: Dariusz Sosnowski <dsosnowski at nvidia.com>
> Cc: Slava Ovsiienko <viacheslavo at nvidia.com>; Bing Zhao <bingz at nvidia.com>;
> Ori Kam <orika at nvidia.com>; Suanming Mou <suanmingm at nvidia.com>; Matan
> Azrad <matan at nvidia.com>; dev at 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 <dsosnowski at 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.