From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Ke Zhang" <ke1x.zhang@intel.com>, <dev@dpdk.org>,
<thomas@monjalon.net>, <ferruh.yigit@amd.com>,
<olivier.matz@6wind.com>, <Yuying.Zhang@intel.com>,
<beilei.xing@intel.com>
Cc: <andrew.rybchenko@oktetlabs.ru>
Subject: RE: [PATCH] net/i40e: disable source pruning
Date: Mon, 9 Jan 2023 08:40:03 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8763D@smartserver.smartshare.dk> (raw)
In-Reply-To: <20230109022027.190627-1-ke1x.zhang@intel.com>
+CC: Andrew, as Ethernet API maintainer
> From: Ke Zhang [mailto:ke1x.zhang@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.zhang@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.
next prev parent reply other threads:[~2023-01-09 7:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 9:04 [dpdk-dev] " Alvin Zhang
2021-10-19 9:38 ` [dpdk-dev] [PATCH v2] " Alvin Zhang
2021-10-20 1:28 ` [dpdk-dev] [PATCH v3] " Alvin Zhang
2022-02-21 8:30 ` Jiang, YuX
2022-02-21 9:35 ` Morten Brørup
2022-12-26 9:03 ` Zhang, Ke1X
2022-12-26 10:26 ` Morten Brørup
2022-12-26 10:27 ` Morten Brørup
2023-01-09 2:20 ` [PATCH] " Ke Zhang
2023-01-09 7:40 ` Morten Brørup [this message]
2023-01-13 12:50 ` Ferruh Yigit
2023-01-30 8:09 ` [PATCH v2] net/i40e: support enabling/disabling " Ke Zhang
2023-01-30 8:41 ` Morten Brørup
2023-01-30 8:58 ` David Marchand
2023-01-31 3:28 ` Zhang, Ke1X
2023-02-01 11:11 ` Thomas Monjalon
2023-02-07 1:40 ` Zhang, Ke1X
2023-02-07 8:35 ` Thomas Monjalon
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=98CBD80474FA8B44BF855DF32C47DC35D8763D@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=Yuying.Zhang@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=ke1x.zhang@intel.com \
--cc=olivier.matz@6wind.com \
--cc=thomas@monjalon.net \
/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).