Re: [PATCH dpdk v3] net/tap: add software MAC address filtering

Stephen Hemminger
2026-03-21T17:06:30Z

On Sat, 21 Mar 2026 15:48:40 +0100
Robin Jarry <rjarry@redhat.com> wrote:

> Linux TAP devices deliver all packets to userspace regardless of the
> PROMISC/ALLMULTI flags on the interface. When promiscuous mode is
> disabled, drop received packets whose destination MAC does not match
> any configured unicast or multicast address.
>
> The receive path checks the destination MAC against the device's
> unicast address table (managed by the ethdev layer), the multicast
> address list (stored by the driver since the ethdev layer does not keep
> a copy), and accepts broadcast unconditionally. Promiscuous and
> all-multicast modes bypass the respective checks.
>
> To support multiple unicast addresses via rte_eth_dev_mac_addr_add(),
> allocate mac_addrs with rte_zmalloc (TAP_MAX_MAC_ADDRS=16) instead of
> pointing into dev_private, and advertise the new limit in dev_infos_get.
>
> Dropped packets are reported via per-queue xstats
> (rx_q<N>_mac_filter_drops).
>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>

Not sure the xstat for mac_filter_drops is needed, since it is what
other devices do as normal operation.

AI review found:

Two issues worth addressing in this patch.
The rte_realloc call in tap_set_mc_addr_list assigns directly back to
pmd->mc_addrs. When realloc fails it returns NULL but leaves the
original allocation intact, so the old pointer is lost and the memory
leaks. Use a temporary variable for the realloc result.

The ops table sets .xstats_reset = tap_stats_reset, but that function
only zeroes the base counters. The new mac_drops xstat is never reset.
Either extend the existing reset or add a dedicated xstats reset
function.