From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56D81C5479D for ; Mon, 9 Jan 2023 07:40:07 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 54DBC40687; Mon, 9 Jan 2023 08:40:06 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 566EC4067C for ; Mon, 9 Jan 2023 08:40:04 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] net/i40e: disable source pruning Date: Mon, 9 Jan 2023 08:40:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8763D@smartserver.smartshare.dk> In-Reply-To: <20230109022027.190627-1-ke1x.zhang@intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] net/i40e: disable source pruning Thread-Index: Adkj0uR7Brkh/btJRBSb5DBwH4n9YwAI1RcQ References: <20211020012831.8480-1-alvinx.zhang@intel.com> <20230109022027.190627-1-ke1x.zhang@intel.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Ke Zhang" , , , , , , Cc: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org +CC: Andrew, as Ethernet API maintainer > From: Ke Zhang [mailto:ke1x.zhang@intel.com] > Sent: Monday, 9 January 2023 03.20 >=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. >=20 > This patch adds a interface in lib/ethdev to support disabling > source pruning to work around above issue. Thank you for the improved patch. >=20 > Bugzilla ID: 648 >=20 > Signed-off-by: Ke Zhang > --- [...] +static cmdline_parse_token_string_t cmd_setllb_enalbe =3D 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 =3D I40E_DEV_PRIVATE_TO_PF(dev->data- > >dev_private); > + struct i40e_hw *hw =3D I40E_PF_TO_HW(pf); > + struct i40e_vsi_context ctxt; > + int ret; > + > + /* Use the FW API if FW >=3D v5.0 */ > + if (hw->aq.fw_maj_ver < 5 && hw->mac.type !=3D 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 >=3D 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 =3D pf->main_vsi_seid; > + ctxt.pf_num =3D hw->pf_id; > + ret =3D 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 =3D I40E_AQ_VSI_TYPE_PF; > + ctxt.info.valid_sections =3D > + rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID); > + if (on) > + ctxt.info.switch_id |=3D > + rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB); > + else > + ctxt.info.switch_id &=3D > + ~rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB); > + > + ret =3D i40e_aq_update_vsi_params(hw, &ctxt, NULL); > + if (ret) > + PMD_DRV_LOG(ERR, "update vsi switch failed, aq_err=3D%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); >=20 > +/** > + * 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.