DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mandal, Anurag" <anurag.mandal@intel.com>
To: "Mandal, Anurag" <anurag.mandal@intel.com>,
	"Morten Brørup" <mb@smartsharesystems.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: RE: [PATCH v3] net/ice: add MAC anti-spoof option
Date: Wed, 17 Dec 2025 14:22:51 +0000	[thread overview]
Message-ID: <CY5PR11MB611686BE0F27B6611461DA8EE4ABA@CY5PR11MB6116.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CY5PR11MB61162578092FBC66127A2EDDE4ABA@CY5PR11MB6116.namprd11.prod.outlook.com>

-----Original Message-----
From: Morten Brørup <mb@smartsharesystems.com>
Sent: 17 December 2025 19:44
To: Richardson, Bruce <bruce.richardson@intel.com>
Cc: Mandal, Anurag <anurag.mandal@intel.com>; dev@dpdk.org; Burakov, Anatoly <anatoly.burakov@intel.com>
Subject: RE: [PATCH v3] net/ice: add MAC anti-spoof option

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 17 December 2025 14.46
> 
> 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.

Sure sounds like it.
Let's hope it's only testpmd, and not a broader issue with the NIC/driver.

> 
> > > 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.

> A new patch with reverted default behavior seems like the proper short-term solution.
> While investigating, we can live with the wrong default behavior, as a "well known bug".
> And the configurability will be helpful for root-causing.

> 
> /Bruce

Hi Morten & Bruce,

Please note, when I sent the patch[v2] with MAC Anti Spoof enabled by default which is the current behaviour without the concerned patch , then no CI issues were reported.
PFB the reference.
https://patches.dpdk.org/project/dpdk/patch/20251116035749.45922-1-anurag.mandal@intel.com/

Root Cause of the CI failure:-
Source Prune is disabled by default while doing that we used to set ICE_AQ_VSI_SW_FLAG_SRC_PRUNE flag as well which is added to prevent transmitted packets from being looped back in some circumstances like the one CI reporting.

Now, if we make MAC anti-spoof disabled by default , we have to clear/not set that ICE_AQ_VSI_SW_FLAG_SRC_PRUNE  flag and  set ICE_AQ_VSI_SW_FLAG_ALLOW_LB flag.

Hence, my initial solution in patch v2 was to keep source prune disabled and mac anti-spoof enabled by default.

Please let me know the way forward.

Thanks,
Anurag

      reply	other threads:[~2025-12-17 14:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13 10:59 [PATCH] net/ice: add MAC anti-spoof disable option Anurag Mandal
2025-11-13 11:35 ` Bruce Richardson
2025-11-16  3:57 ` [PATCH v2] net/ice: add MAC anti-spoof option Anurag Mandal
2025-11-16  7:43   ` Morten Brørup
2025-11-17  5:22     ` Mandal, Anurag
2025-11-17  9:05       ` Morten Brørup
2025-12-02  8:17         ` Mandal, Anurag
2025-12-02  9:00           ` Morten Brørup
2025-12-02  9:14             ` Mandal, Anurag
2025-12-02 14:25               ` Thomas Monjalon
2025-12-02 17:10                 ` Morten Brørup
2025-12-03 10:41 ` [PATCH v3] " Anurag Mandal
2025-12-03 11:41   ` Morten Brørup
2025-12-03 14:36     ` Mandal, Anurag
2025-12-03 14:47       ` Morten Brørup
2025-12-11 15:22         ` Bruce Richardson
2025-12-17 11:52           ` Bruce Richardson
2025-12-17 12:37             ` Morten Brørup
2025-12-17 13:46               ` Bruce Richardson
2025-12-17 14:13                 ` Morten Brørup
2025-12-17 14:18                   ` Mandal, Anurag
2025-12-17 14:22                     ` Mandal, Anurag [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY5PR11MB611686BE0F27B6611461DA8EE4ABA@CY5PR11MB6116.namprd11.prod.outlook.com \
    --to=anurag.mandal@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).