On Wed, Dec 17, 2025 at 01:37:16PM +0100, Morten Brørup wrote: > > 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"? >
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
