DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>,
	"Mandal, Anurag" <anurag.mandal@intel.com>
Cc: <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 13:37:16 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F655F2@smartserver.smartshare.dk> (raw)
In-Reply-To: <aUKZmzuLWYguKOlE@bricha3-mobl1.ger.corp.intel.com>

> 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"?

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


  reply	other threads:[~2025-12-17 12:37 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 [this message]
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

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=98CBD80474FA8B44BF855DF32C47DC35F655F2@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=anatoly.burakov@intel.com \
    --cc=anurag.mandal@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /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).