+CC: Andrew, as Ethernet API maintainer
> From: Ke Zhang [mailto:ke1x.zh...@intel.com]
> Sent: Monday, 9 January 2023 03.20
>
> VRRP advertisement packets are dropped on i40e PF devices because
> when a MAC address is added to a device, packets originating from
> that MAC address are dropped.
>
> This patch adds a interface in lib/ethdev to support disabling
> source pruning to work around above issue.
Thank you for the improved patch.
>
> Bugzilla ID: 648
>
> Signed-off-by: Ke Zhang <ke1x.zh...@intel.com>
> ---
[...]
+static cmdline_parse_token_string_t cmd_setllb_enalbe =
Typo: enalbe -> enable.
[...]
> +/* i40e_enable_pf_local_lb
> + * @pf: pointer to the pf structure
> + *
> + * allow local loopback on pf
> + */
> +static int
> +i40e_enable_pf_local_lb(struct rte_eth_dev *dev, int on)
> +{
> + struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data-
> >dev_private);
> + struct i40e_hw *hw = I40E_PF_TO_HW(pf);
> + struct i40e_vsi_context ctxt;
> + int ret;
> +
> + /* Use the FW API if FW >= v5.0 */
> + if (hw->aq.fw_maj_ver < 5 && hw->mac.type != I40E_MAC_X722) {
> +#ifdef TREX_PATCH
> + /* Most of our customers do not have latest FW */
> + PMD_INIT_LOG(INFO, "FW < v5.0, cannot enable local
> loopback");
> +#else
> + PMD_INIT_LOG(ERR, "FW < v5.0, cannot enable local
> loopback");
> +#endif
> + return I40E_NOT_SUPPORTED;
> + }
Can this bug not be fixed without requiring FW >= 5.0?
If VRRP is not supported with older FW, perhaps you could also log a warning
when a VRRP MAC address is added to the NIC (and the FW is too old, or local_lb
is disabled). Just an idea; it will help people debug issues with VRRP in
production.
> +
> + memset(&ctxt, 0, sizeof(ctxt));
> + ctxt.seid = pf->main_vsi_seid;
> + ctxt.pf_num = hw->pf_id;
> + ret = i40e_aq_get_vsi_params(hw, &ctxt, NULL);
> + if (ret) {
> + PMD_DRV_LOG(ERR, "cannot get pf vsi config, err %d, aq_err
> %d",
> + ret, hw->aq.asq_last_status);
> + return ret;
> + }
> + ctxt.flags = I40E_AQ_VSI_TYPE_PF;
> + ctxt.info.valid_sections =
> + rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
> + if (on)
> + ctxt.info.switch_id |=
> + rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB);
> + else
> + ctxt.info.switch_id &=
> + ~rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB);
> +
> + ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
> + if (ret)
> + PMD_DRV_LOG(ERR, "update vsi switch failed, aq_err=%d",
> + hw->aq.asq_last_status);
> +
> + return ret;
> +}
[...]
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index c129ca1eaf..c4888ebd62 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -3437,6 +3437,21 @@ int rte_eth_dev_set_mtu(uint16_t port_id,
> uint16_t mtu);
> */
> int rte_eth_dev_vlan_filter(uint16_t port_id, uint16_t vlan_id, int
> on);
>
> +/**
> + * Enable/Disable local Loopback for VSIs that are used as uplink of a
> software
> + * (cascaded) VEB, VEPA or Port Virtualizer.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param on
> + * If > 0, enable local Loopback.
> + * Otherwise, disable local Loopback.
> + * @return
> + * - (0) if successful.
> + * - negative if failed.
> + */
> +int rte_eth_dev_enable_local_lb(uint16_t port_id, int on);
> +
Local Loopback usually means that packets queued for TX are looped back into RX
by the NIC or PHY.
If the Intel X710/XXV710/XL710 "Source Pruning" feature only applies to
egressing packets internally looped back to ingress by VEB, this patch makes
some sense, although I wish you could come up with a better name for it than
Local Loopback.
However, if the "Source Pruning" feature also applies to packets ingressing
from the physical Ethernet interface, this naming and behavior is
counterintuitive. In this case, "Source Pruning" is a special filter, which
other NICs don't apply to ingressing packets, so the PMD should not enable the
filter (and thus behave differently than all other NICs) unless explicitly
enabled by the application.
