From: Bruce Richardson <bruce.richardson@intel.com>
To: Anurag Mandal <anurag.mandal@intel.com>
Cc: <dev@dpdk.org>, <anatoly.burakov@intel.com>
Subject: Re: [PATCH] net/ice: add MAC anti-spoof disable option
Date: Thu, 13 Nov 2025 11:35:47 +0000 [thread overview]
Message-ID: <aRXCkzTTkhjwWLI1@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20251113105914.34949-1-anurag.mandal@intel.com>
On Thu, Nov 13, 2025 at 10:59:14AM +0000, Anurag Mandal wrote:
> VRRP advertisement packets are dropped as TX-errors upon transmission from
> a vsi of ice PF due to MAC anti-spoof check. There is no way to disable
> this check in the Tx direction to avoid these packets being dropped.
>
> This patch introduces devarg "mac-anti-spoof-disable" 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>
See feedback inline below.
/Bruce
> ---
> doc/guides/nics/ice.rst | 11 +++++++++++
> drivers/net/intel/ice/ice_ethdev.c | 22 ++++++++++++++++++++++
> drivers/net/intel/ice/ice_ethdev.h | 1 +
> 3 files changed, 34 insertions(+)
>
> diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
> index 6cc27cefa7..bc86de0081 100644
> --- a/doc/guides/nics/ice.rst
> +++ b/doc/guides/nics/ice.rst
> @@ -194,6 +194,17 @@ Runtime Configuration
>
> -a 80:00.0,source-prune=1
>
> +- ``MAC Anti-spoof Disable`` (default ``0``)
> +
> + 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.
> +
> + MAC Anti-spoof can be disabled by setting the devargs parameter ``mac-anti-spoof-disable``,
> + for example::
> +
> + -a 80:00.0,mac-anti-spoof-disable=1
> +
I dislike as a point of principle having options with "disable" in the
name, because it means that the normal logic for on/off is reversed. For
example, in this case to enable anti-spoof you set it to 0. Also, having
disable in the name makes the name longer!
How about having this setting called "mac-anti-spoof" and setting the
default to 1.
> - ``Protocol extraction for per queue``
>
> Configure the RX queues to do protocol extraction into mbuf for protocol
> diff --git a/drivers/net/intel/ice/ice_ethdev.c b/drivers/net/intel/ice/ice_ethdev.c
> index c1d92435d1..a0eae74bbb 100644
> --- a/drivers/net/intel/ice/ice_ethdev.c
> +++ b/drivers/net/intel/ice/ice_ethdev.c
> @@ -42,6 +42,7 @@
> #define ICE_DDP_LOAD_SCHED_ARG "ddp_load_sched_topo"
> #define ICE_TM_LEVELS_ARG "tm_sched_levels"
> #define ICE_SOURCE_PRUNE_ARG "source-prune"
> +#define ICE_MAC_ANTI_SPOOF_DISABLE "mac-anti-spoof-disable"
> #define ICE_LINK_STATE_ON_CLOSE "link_state_on_close"
>
> #define ICE_CYCLECOUNTER_MASK 0xffffffffffffffffULL
> @@ -60,6 +61,7 @@ static const char * const ice_valid_args[] = {
> ICE_DDP_LOAD_SCHED_ARG,
> ICE_TM_LEVELS_ARG,
> ICE_SOURCE_PRUNE_ARG,
> + ICE_MAC_ANTI_SPOOF_DISABLE,
> ICE_LINK_STATE_ON_CLOSE,
> NULL
> };
> @@ -1768,6 +1770,20 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
> vsi_ctx.info.sw_flags |=
> ICE_AQ_VSI_SW_FLAG_SRC_PRUNE;
> }
> + /* MAC Anti-Spoof */
> + if (ad->devargs.mac_anti_spoof_disable == 1) {
> + /* Disable mac anti-spoof check in the
> + * Tx direction to avoid getting dropped
> + * as TX-errors for VRRP support when
> + * mac-anti-spoof-disable devarg is set
> + */
> + vsi_ctx.info.sw_flags &=
> + ~ICE_AQ_VSI_SW_FLAG_SRC_PRUNE;
If the source prune feature conflicts with the anti-spoof one in some way,
then we need to check at devargs processing time for conflicts and warn the
user. Also, if the user specifies on flag which changes the default of the
other, a logging message should be emitted (e.g. at INFO or NOTICE level)
> + vsi_ctx.info.sw_flags |=
> + ICE_AQ_VSI_SW_FLAG_ALLOW_LB;
> + vsi_ctx.info.sec_flags =
> + ICE_AQ_VSI_SEC_FLAG_ENA_MAC_ANTI_SPOOF;
This seems strange to me. When anti-spoof disable flag is set, we turn on
the ENA (enable, right?) MAC_ANTI_SPOOF flag?
> + }
> cfg = ICE_AQ_VSI_PROP_SW_VALID;
> vsi_ctx.info.valid_sections |= rte_cpu_to_le_16(cfg);
> vsi_ctx.info.sw_flags2 = ICE_AQ_VSI_SW_FLAG_LAN_ENA;
> @@ -2467,6 +2483,11 @@ static int ice_parse_devargs(struct rte_eth_dev *dev)
> if (ret)
> goto bail;
>
> + ret = rte_kvargs_process(kvlist, ICE_MAC_ANTI_SPOOF_DISABLE,
> + &parse_bool, &ad->devargs.mac_anti_spoof_disable);
> + if (ret)
> + goto bail;
> +
> ret = rte_kvargs_process(kvlist, ICE_LINK_STATE_ON_CLOSE,
> &parse_link_state_on_close, &ad->devargs.link_state_on_close);
>
> @@ -7732,6 +7753,7 @@ RTE_PMD_REGISTER_PARAM_STRING(net_ice,
> ICE_DDP_LOAD_SCHED_ARG "=<0|1>"
> ICE_TM_LEVELS_ARG "=<N>"
> ICE_SOURCE_PRUNE_ARG "=<0|1>"
> + ICE_MAC_ANTI_SPOOF_DISABLE "=<0|1>"
> ICE_RX_LOW_LATENCY_ARG "=<0|1>"
> ICE_LINK_STATE_ON_CLOSE "=<down|up|initial>");
>
> diff --git a/drivers/net/intel/ice/ice_ethdev.h b/drivers/net/intel/ice/ice_ethdev.h
> index 72ed65f13b..9b36627d12 100644
> --- a/drivers/net/intel/ice/ice_ethdev.h
> +++ b/drivers/net/intel/ice/ice_ethdev.h
> @@ -617,6 +617,7 @@ struct ice_devargs {
> uint8_t ddp_load_sched;
> uint8_t tm_exposed_levels;
> uint8_t source_prune;
> + uint8_t mac_anti_spoof_disable;
> int link_state_on_close;
> int xtr_field_offs;
> uint8_t xtr_flag_offs[PROTO_XTR_MAX];
> --
> 2.34.1
>
prev parent reply other threads:[~2025-11-13 11:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 10:59 Anurag Mandal
2025-11-13 11:35 ` Bruce Richardson [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=aRXCkzTTkhjwWLI1@bricha3-mobl1.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=anurag.mandal@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).