Re: [PATCH net] macsec: Support VLAN-filtering lower devices

[Cosmin Ratiu <cratiu@nvidia.com>]

On Fri, 2026-01-09 at 11:26 +0100, Sabrina Dubroca wrote:
> 2026-01-07, 12:47:23 +0200, Cosmin Ratiu wrote:
> > VLAN-filtering is done through two netdev features
> > (NETIF_F_HW_VLAN_CTAG_FILTER and NETIF_F_HW_VLAN_STAG_FILTER) and
> > two
> > netdev ops (ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid).
> > 
> > Implement these and advertise the features if the lower device
> > supports
> > them. This allows proper VLAN filtering to work on top of macsec
> > devices, when the lower device is capable of VLAN filtering.
> > As a concrete example, having this chain of interfaces now works:
> > vlan_filtering_capable_dev(1) -> macsec_dev(2) ->
> > macsec_vlan_dev(3)
> > 
> > Before the "Fixes" commit this used to accidentally work because
> > the
> > macsec device (and thus the lower device) was put in promiscuous
> > mode
> > and the VLAN filter was not used. But after that commit correctly
> > made
> > the macsec driver expose the IFF_UNICAST_FLT flag, promiscuous mode
> > was
> > no longer used and VLAN filters on dev 1 kicked in. Without support
> > in
> > dev 2 for propagating VLAN filters down, the register_vlan_dev ->
> > vlan_vid_add -> __vlan_vid_add -> vlan_add_rx_filter_info call from
> > dev
> > 3 is silently eaten (because vlan_hw_filter_capable returns false
> > and
> > vlan_add_rx_filter_info silently succeeds).
> 
> We only want to propagate VLAN filters when macsec offload is used,
> no? If offload isn't used, the lower device should be unaware of
> whatever is happening on top of macsec, so I don't think non-
> offloaded
> setups are affected by this?

VLAN filters are not related to macsec offload, right? It's about
informing the lower netdevice which VLANs should be allowed. Without
this patch, the VLAN-tagged packets intended for the macsec vlan device
are discarded by the lower device VLAN filter.

> Even when offload is used, the lower device should probably handle
> "ETH + VLAN 5" differently from "ETH + MACSEC + VLAN 5", but that may
> not be possible with just the existing device ops.

I don't see how macsec plays a role into how the lower device handles
VLANs. From the protocol diagrams, I see that it's ETH + VLAN 5 +
MACSEC, the VLAN isn't encrypted if present.

Cosmin.