RE: [PATCH v2] net/ice: add MAC anti-spoof option

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, 2 December 2025 15.25
> 
> Hello,
> 
> Top posting makes this thread difficult to follow.
> 
> My quick understanding is that it is an offload feature,
> and I don't understand why it is not handled as such in ethdev API.

Yes, it is. Similar to e.g. "promiscuous mode" is an Rx offload to control which packets are filtered or let through at Rx.

I consider the RTE_ETH_RX_OFFLOAD_xxx and RTE_ETH_TX_OFFLOAD_xxx flags relatively scarce, so I'm very skeptical about using them for relatively exotic offloads like mac-anti-spoof.

We have dedicated Ethdev APIs to control "promiscuous mode", but I'm not sure we want dedicated Ethdev APIs for every filter an NIC vendor can come up with.

Which is why I suggested a generic filter API as an alternative idea.

Maybe we should just consider them offloads, and use RTE_ETH_RX_OFFLOAD_xxx and RTE_ETH_TX_OFFLOAD_xxx flags. Then we can rely on the existing infrastructure for those. My suggested filter API is really just an extension of these.

-Morten

> 
> 
> 02/12/2025 10:14, Mandal, Anurag:
> > Hi Morten Brørup,
> >
> > Ok. I will make Mac-anti-spoof disabled by default, gave option to
> enable it  and send a new patch.
> >
> > Thank you.
> >
> > Regards,
> > Anurag M
> >
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: 02 December 2025 14:31
> > To: Mandal, Anurag <anurag.mandal@intel.com>; dev@dpdk.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Burakov, Anatoly
> <anatoly.burakov@intel.com>; thomas@monjalon.net;
> andrew.rybchenko@oktetlabs.ru; Stephen Hemminger
> <stephen@networkplumber.org>
> > Subject: RE: [PATCH v2] net/ice: add MAC anti-spoof option
> >
> > +TO: Stephen Hemminger, might have some kernel-related insights on
> this.
> >
> > > From: Mandal, Anurag [mailto:anurag.mandal@intel.com]
> > > Sent: Tuesday, 2 December 2025 09.17
> > >
> > > Hi Morten Brørup,
> > >
> > > Apologies for late reply but as the patch was deferred from DPDK
> 25.11.
> > > Hence, I was waiting.
> > > PFB my answers.
> > >
> > > Q1: " Please disable anti-spoof filtering by default, and provide
> an
> > > option to enable it.
> > > Like source-prune."
> > > [Ans]: MAC anti-spoof is enabled by default in kernel ice driver.
> > > Hence, it seems a better idea to make it enabled by default to keep
> it
> > > in sync with kernel and in terms of security.
> >
> > Mac-source-prune is disabled by default in DPDK, although it is
> enabled by default in the kernel.
> > Mac-anti-spoof should behave the same way, i.e. disabled by default
> in DPDK.
> >
> > Also, consider that the kernel is mainly designed for client/server
> applications, while DPDK is mainly designed for packet forwarding
> purposes.
> > With that in mind, default enabled makes sense for the kernel, and
> default disabled makes sense for DPDK.
> >
> > >
> > > Q2: " Is support for "vlan-anti-spoof" in the pipeline?"
> > > [Ans]: Not sure but " vlan_anti_spoof_on" is present in code.
> >
> > OK.
> >
> > >
> > > Q3: " What are your thoughts about the generic Ethdev APIs I
> > > suggested, instead of driver specific devargs?"
> > > [Ans]: It is unlikely that a user would want these mac anti-
> spoof/src
> > > prune to be set/reset dynamically. Hence,  it seems devargs likely
> be
> > > a better solution.
> > > Generic Ethdev APIs is a good idea but should be taken separately
> as
> > > it will have much beyond scope than this and would need significant
> > > effort.
> > > Also, that again bring the dynamic nature into the picture.
> >
> > Good point about not needing the dynamic ability. I agree with that.
> > But devargs are somewhat difficult to work with for applications not
> built for specific ethdev drivers. E.g. our application detects
> available hardware at runtime, and configures it appropriately. Generic
> APIs are much easier to work with than individual driver-specific
> devargs.
> > So I prefer not to introduce more driver specific devargs.
> >
> > I acknowledge that my Ethdev API extension idea is feature creep, so
> I will not make it a hard requirement for this patch.
> > And when mac-anti-spoof is disabled by default (which I do consider a
> hard requirement!), the devarg parameter is reduced to something that
> enables some exotic filter, which I don't object to.
> >
> > >
> > > Thank you.
> > >
> > > Regards,
> > > Anurag M
> > >
> > > -----Original Message-----
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > Sent: 17 November 2025 14:36
> > > To: Mandal, Anurag <anurag.mandal@intel.com>; dev@dpdk.org;
> > > Richardson, Bruce <bruce.richardson@intel.com>; Burakov, Anatoly
> > > <anatoly.burakov@intel.com>; thomas@monjalon.net;
> > > andrew.rybchenko@oktetlabs.ru
> > > Subject: RE: [PATCH v2] net/ice: add MAC anti-spoof option
> > >
> > > > From: Mandal, Anurag [mailto:anurag.mandal@intel.com]
> > > > Sent: Monday, 17 November 2025 06.22
> > > >
> > > > Hi Morten Brørup,
> > > >
> > > > Thanks for your mail and review. PFB my answers.
> > > >
> > > > " This is the same story as with Source Prune.
> > > > Please disable source-prune filtering by default, and provide an
> > > > option to enable it.
> > > > Also, suggest shortening the devargs name to simply "anti-spoof",
> > > like
> > > > "source-prune"; they both operate on MAC basis."
> > > >
> > > > [Ans]: Source prune is disabled by default and option to enable
> the
> > > > same has been already committed:[
> > > >
> > >
> https://github.com/DPDK/dpdk/commit/980c840a646a2c8ae49a291c17baf20a74
> > > > f
> > > > 36086].
> > >
> > > Sorry, there was a typo... I meant to write:
> > > Please disable anti-spoof filtering by default, and provide an
> option
> > > to enable it.
> > > Like source-prune.
> > >
> > > > I also wanted to shorten the name to "anti-spoof" but I found
> > > > something called " vsi->vlan_anti_spoof_on" in the same file.
> > > > Hence, to distinguish between them, used "mac-anti-spoof".
> > >
> > > OK. Then "mac-anti-spoof" is a good choice.
> > >
> > > Is support for "vlan-anti-spoof" in the pipeline?
> > >
> > > What are your thoughts about the generic Ethdev APIs I suggested,
> > > instead of driver specific devargs?
> > >
> > > >
> > > > Thank you.
> > > >
> > > > Regards,
> > > > Anurag M
> > > >
> > > > -----Original Message-----
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > Sent: 16 November 2025 13:14
> > > > To: Mandal, Anurag <anurag.mandal@intel.com>; dev@dpdk.org;
> > > > Richardson, Bruce <bruce.richardson@intel.com>; Burakov, Anatoly
> > > > <anatoly.burakov@intel.com>; thomas@monjalon.net;
> > > > andrew.rybchenko@oktetlabs.ru
> > > > Subject: RE: [PATCH v2] net/ice: add MAC anti-spoof option
> > > >
> > > > +TO: Ethdev maintainers, regarding new Ethdev APIs
> > > >
> > > > > From: Anurag Mandal [mailto:anurag.mandal@intel.com]
> > > > > Sent: Sunday, 16 November 2025 04.58
> > > > >
> > > > > VRRP advertisement packets are dropped as TX-errors upon
> > > > > transmission from a vsi of ice PF due to MAC anti-spoof check
> > > > > which is enabled by default.
> > > > > There is no way to disable this check in the Tx direction to
> avoid
> > > > > these packets being dropped.
> > > > >
> > > > > This patch introduces devargs "mac-anti-spoof" to allow user to
> > > > > disable MAC anti-spoof check. Disable MAC Anti-spoof check in
> the
> > > Tx
> > > > > direction to avoid getting dropped as TX-errors upon packet
> > > > > transmission when their source MAC address matches one of the
> MAC
> > > > > addresses assigned to that same NIC port.
> > > > >
> > > > > Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
> > > > > ---
> > > >
> > > > This is the same story as with Source Prune.
> > > > Please disable source-prune filtering by default, and provide an
> > > > option to enable it.
> > > > Also, suggest shortening the devargs name to simply "anti-spoof",
> > > like
> > > > "source-prune"; they both operate on MAC basis.
> > > >
> > > > Let's make something generic instead, to replace those silly
> devargs.
> > > > We have individual Ethdev APIs to enable/disable various Rx
> > > filtering,
> > > > e.g. "promiscuous", "all multicast".
> > > > Obviously, we don't want to introduce new APIs for every semi-
> exotic
> > > > filter any NIC may offer, like "source prune" and "anti spoof",
> but
> > > we
> > > > could introduce a set of generic Ethdev APIs to support filters
> such
> > > > as these, using a bitfield enum. E.g.:
> > > >
> > > > /* Enable one or more filters. */
> > > > int rte_ethdev_filter_enable(uin16_t port_id, uint64_t filter);
> > > >
> > > > /* Disable one or more filters. */
> > > > int rte_ethdev_filter_disable(uin16_t port_id, uint64_t filter);
> > > >
> > > > /* Get bit field of filters enabled. */ int64_t
> > > > rte_ethdev_filter_get(uin16_t port_id);
> > > >
> > > > /* Get bit field of filters supported by device. */ int64_t
> > > > rte_ethdev_filter_capa(uin16_t port_id); /**/
> > > >
> > > > /** Destination MAC must match NIC's MAC address.
> > > >  * (This is the inverse of Promiscuous.)
> > > >  * Default enabled.
> > > >  */
> > > > #define RTE_ETH_FILTER_RX_NON_PROMISC RTE_BIT64(0)
> > > > /** Multicast Hash.
> > > >  * (This is the inverse of All Multicast.)
> > > >  * Default enabled.
> > > >  */
> > > > #define RTE_ETH_FILTER_RX_MULTICAST RTE_BIT64(1)
> > > > /** Source Prune.
> > > >  * [Insert description here.]
> > > >  */
> > > > #define RTE_ETH_FILTER_RX_SOURCE_PRUNE RTE_BIT64(2)
> > > > /* Add new Rx filters here, in increasing order. */
> > > > /* Add new Tx filters here, in decreasing order. */
> > > > /** Anti-Spoof.
> > > >  * [Insert description here.]
> > > >  */
> > > > #define RTE_ETH_FILTER_RX_SOURCE_PRUNE RTE_BIT64(62)
> > > > /** Used for error return values which are negative. */
> > > > #define RTE_ETH_FILTER_ERROR           RTE_BIT64(63)
> >
> >
> 
> 
> 
>