Re: [PATCH v3] net/ice: add MAC anti-spoof option

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Dec 17, 2025 at 01:37:16PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 17 December 2025 12.53
> > 
> > On Thu, Dec 11, 2025 at 03:22:32PM +0000, Bruce Richardson wrote:
> > > On Wed, Dec 03, 2025 at 03:47:08PM +0100, Morten Brørup wrote:
> > > > > From: Mandal, Anurag [mailto:anurag.mandal@intel.com]
> > > > > Sent: Wednesday, 3 December 2025 15.36
> > > > >
> > > > > Hi Morten Brørup,
> > > > >
> > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > Sent: 03 December 2025 17:11
> > > > > > @@ -1761,13 +1763,39 @@ ice_setup_vsi(struct ice_pf *pf, enum
> > > > > > ice_vsi_type type)
> > > > > >  		/* Source Prune */
> > > > > >  		if (ad->devargs.source_prune != 1) {
> > > > > >  			/* Disable source prune to support VRRP
> > > > > > -			 * when source-prune devarg is not set
> > > > > > +			 * when source-prune devargs is not set
> > > > > >  			 */
> > > > > >  			vsi_ctx.info.sw_flags =
> > > > > >  				ICE_AQ_VSI_SW_FLAG_LOCAL_LB;
> > > > > > -			vsi_ctx.info.sw_flags |=
> > > > > > +		} else { /* Enable Source Prune in Rx */
> > > > > > +			vsi_ctx.info.sw_flags =
> > > > > >  				ICE_AQ_VSI_SW_FLAG_SRC_PRUNE;
> > > > > >  		}
> > > > >
> > > > > This looks like a bug fix related to Source Prune?
> > > > >
> > > > > Ans: Not exactly.
> > > > > Initially, Source Prune was disabled, and MAC Anti-spoof check
> > was
> > > > > enabled by default. This was done by following:-
> > > > > Source Prune is disabled by setting local loopback with
> > > > > ICE_AQ_VSI_SW_FLAG_LOCAL_LB flag in the Rx direction.
> > > > > ICE_AQ_VSI_SW_FLAG_SRC_PRUNE is added to prevent transmitted
> > packets
> > > > > from being looped back in some circumstances.
> > > > > Now, MAC Anti-spoof check can be disabled by clearing both
> > > > > ICE_AQ_VSI_SW_FLAG_SRC_PRUNE and
> > > > > ICE_AQ_VSI_SEC_FLAG_ENA_MAC_ANTI_SPOOF flags and setting Tx
> > loopback
> > > > > with
> > > > > ICE_AQ_VSI_SW_FLAG_ALLOW_LB flag in the Tx direction.
> > > > >
> > > > > As we moved to making both source prune and mac anti-spoof check
> > > > > disabled by default, I thought no point to set
> > > > > ICE_AQ_VSI_SW_FLAG_SRC_PRUNE during source prune disable and then
> > > > > clearing it to disable mac anti-spoof.
> > > >
> > > > OK. Thank you for elaborating.
> > > >
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > > Anurag M
> > > >
> > > > Note to maintainers:
> > > > This devarg is like the Source Prune devarg.
> > > > If we want to elevate these exotic features into proper Ethdev
> > APIs, it should be done for both devargs in a separate patch.
> > > >
> > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > >
> > > Applied to dpdk-next-net-intel.
> > >
> > Unfortunately, this patch causes changes in the driver behaviour
> > leading to
> > CI failures. These issues can be seen with testpmd where packets are
> > looping back inside a nic port unexpectedly.
> 
> Can you please elaborate "packets are looping back"?
> 

When testpmd is configured for mac forwarding, sending in a single packet
leads to a constant stream of packets being handled by testpmd.

> If the packets egress on one physical port, they certainly shouldn't ingress back on the same physical port.
> 
> However, if they egress on one virtual port, and are internally switched to ingress on another virtual port on the same physical port, I would consider that expected behavior - the same would happen if those ports were physical and connected to the same physical switch.
> 
> If they are ingressing on the same virtual port they were sent on, that would seem like a bug in the NICs virtual switch. A physical switch normally wouldn't transmit packets back out on the port they ingressed on.
> 

Not exactly sure what is happening internally, it needs some investigation.

> > Therefore, this patch
> > needs to
> > be dropped from next-net-intel.
> > 
> > Can you please do a new version adding the feature you require while
> > still
> > keeping the existing default behaviour.  I'm going to move the patch
> > status
> > from accepted to "changes requested" in patchwork, in anticipation of a
> > new
> > version.
> > 
> > Regards,
> > /Bruce
> 
> This sounds like the CI needs to be fixed.
> Why does the CI expect this kind of filtering to be enabled by default?
> I wouldn't expect other NICs to perform similar filtering.
> 
It could well be a testing issue, or a combination of incorrect default
behaviour and a sub-optimal test case. However, until that is fully
root-caused, I'm backing out the patch for safety.

/Bruce