> From: Bruce Richardson [mailto:[email protected]] > 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:[email protected]] > > > > Sent: Wednesday, 3 December 2025 15.36 > > > > > > > > Hi Morten Brørup, > > > > > > > > From: Morten Brørup <[email protected]> > > > > 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 <[email protected]> > > > > > 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"? 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. > 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. -Morten
