RE: [Intel-wired-lan] [PATCH iwl-next v4 7/7] ice: in VEB, prevent "cross-vlan" traffic from hitting loopback

[Romanowski, Rafal]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf Of Jakub
> Slepecki
> Sent: Wednesday, February 4, 2026 4:44 PM
> To: intel-wired-lan@xxxxxxxxxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Nguyen, Anthony L
> <anthony.l.nguyen@xxxxxxxxx>; michal.swiatkowski@xxxxxxxxxxxxxxx; Slepecki,
> Jakub <jakub.slepecki@xxxxxxxxx>; Loktionov, Aleksandr
> <aleksandr.loktionov@xxxxxxxxx>
> Subject: [Intel-wired-lan] [PATCH iwl-next v4 7/7] ice: in VEB, prevent "cross-
> vlan" traffic from hitting loopback
> 
> In Virtual Ethernet Bridge (VEB) mode, we use MAC filters to forward traffic
> between two VFs.  We also use VLAN filters to prune potential destinations, so
> that they don't cross VLANs.  In case a VF in VLAN X sends a packet to a MAC
> address matching another VF but in VLAN Y, both these filters will be hit.  Packet
> will be sent to loopback-only to VF in VLAN Y, but VLAN filter will prune its VSI
> from the destination list leaving the packet stranded in the internal switch and
> thus dropped.
> 
> Since there is no destination for the packet in the VLAN X, it should instead be
> sent to the wire.
> 
> To fix this, we introduce MAC,VLAN filters in place of MAC-only filters if VSI is part
> of any VLAN.  We consider VSI part of a VLAN if it has a PVID set, or if it has a
> specific VLAN filter and does not have a VLAN
> 0 filter.
> 
> This approach does not attempt to fix interactions with upper devices.
> If an upper vlan device requests a separate MAC address filter resulting in a call
> to __dev_uc_sync, the VSI will start receiving all packets destined for this MAC
> and not just within the VLAN.  I don't see a straight-forward way to resolve this:
> information about MAC and VLAN filters coming from kernel to driver is
> disconnected from one another and from the device that requests it.  It could be
> worked around by, for example, tracking all upper devices with netdev
> notifications and adjusting the filters there.  Hence, the scope is limited to VF
> traffic.
> 
> Following situations were considered for VLAN filters additions, removal, or
> changes:
> 
> 1. ice changes VF's vlan
> 2. VF is reset and rebuilt
> 3. vlan device attaches above a PF or a VF
> 
> And same for MAC filters:
> 
> 4. PF's MAC is changed
> 5. PF changes MAC of a VF
> 6. VF's MAC is changed
> 7. ndo_set_rx_mode et al
> 
> When VLAN is assigned to a VF in (1), the affected VF is reset and rebuild.  This
> makes (1) the same as (2).  We end up with two cases where VLAN filters are
> added: (2) and (3).
> 
> To correctly handle (1-2), we move the VLAN filters initialization before the MAC
> filters initialization, since MAC filters now depend on VLAN filters presence.
> These two handle PVID (or lack of thereof) and because they are always
> associated with a reset, we don't need to consider updating MAC and MAC,VLAN
> filters afterwards.
> 
> In (3), we will always have a lower device that is expected to receive all packets
> for its MAC regardless of VLAN tag.  Because of the caveat described above, we
> will do the same for each MAC address associated with the interface regardless
> of VLANs.  The result is we only have MAC-only filters in this case.
> 
> When we create MAC filters in (4-7) we now check for existing VLAN filters and
> depending on PVID and VLAN 0 presence we decide to create, respectively, a
> MAC and MAC,VLAN filter pair, or a MAC filter.  This is done implicitly when
> requesting to remove old MAC and add new MAC, so no change is required to this
> flow.
> 
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@xxxxxxxxxxxxxxx>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@xxxxxxxxx>
> Signed-off-by: Jakub Slepecki <jakub.slepecki@xxxxxxxxx>
> 
> ---
> Note the /a.s. dead/ branch in ice_fltr.c.  I decided to make it explicit, but it can
> be merged into VLAN 0 branch as well (with or without a comment), because
> their final effect is exactly the same.
> 
> No changes in v4.
> No changes in v3.
> No changes in v2.
> ---
>  drivers/net/ethernet/intel/ice/ice_fltr.c   | 71 +++++++++++++++++++--
>  drivers/net/ethernet/intel/ice/ice_fltr.h   |  6 +-
>  drivers/net/ethernet/intel/ice/ice_main.c   |  8 +--
>  drivers/net/ethernet/intel/ice/ice_switch.c |  2 +-
> drivers/net/ethernet/intel/ice/ice_switch.h |  2 +
> drivers/net/ethernet/intel/ice/ice_vf_lib.c |  8 +--
>  6 files changed, 83 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_fltr.c
> b/drivers/net/ethernet/intel/ice/ice_fltr.c
> index 96a4e4b1b3fc..c0fc1bced167 100644
> --- a/drivers/net/ethernet/intel/ice/ice_fltr.c
> +++ b/drivers/net/ethernet/intel/ice/ice_fltr.c
> @@ -3,6 +3,7 @@


Tested-by: Rafal Romanowski <rafal.romanowski@xxxxxxxxx>