From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <3chas3@gmail.com> Received: from mail-io0-f195.google.com (mail-io0-f195.google.com [209.85.223.195]) by dpdk.org (Postfix) with ESMTP id 809501B513 for ; Thu, 2 Aug 2018 23:19:55 +0200 (CEST) Received: by mail-io0-f195.google.com with SMTP id i18-v6so3251383ioj.13 for ; Thu, 02 Aug 2018 14:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jcW1Hf7abhbsWP3ZcvIrQpvA7RdL9BNZS+BEPjZg4GU=; b=oVqMWsHWeOqN6VNJX4lj5RRdol8tKB8QceJB/1HMvkxkKxg1IwbibA3rW2OjBy+r+j ScRoJhD3T9z2/6jdSFBA/VbViyiURGvaMIJj8uAxOjR/6AFM2cR9zXsCKntDNyQTIjfm 0NSzgNHBLWrKUq1Co7CMt8dckI9vkrl43MrLIxlze/wtoty7wXIfVwp1BEao1nmA5z5u WsBjGmRjRDRhblBBnRkGbyqG/C3SVeTYaqFztGn1V7S/rhYP71N+YgAtTJZTHrEQqeum foJHWY/canuisbONMU3ztcxICILTPkXRSBTKRa3u21HH8paBuus5JpnM8i2miuo4/eRC ZIJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jcW1Hf7abhbsWP3ZcvIrQpvA7RdL9BNZS+BEPjZg4GU=; b=c2x3nLt9rSC9lQ2tg/kUwmTDOMC5cyhQrbosP61XpyJmkxdtDuSBq472X/ROAO11KU Q+pNU1c/WzU7anc4+81C/3AeGmnp+pOvFVYOGb/OyHhg2/y9oki5OykC3mq3smaa47v4 0UyNhyFyt8LJhLzaT+qSD1a2QejC3bq/FX1ArwbO3MyDUSinogbwO/ifY5l3meUHTHOt uwczIJAuOrAcK3GNKzDWxVGcGN9xAkNZ64ZhAgTxCmWjNbM8Q8Tfoegukyk11cvrzB4w Zj/gkHgvy71/dwuvLMO/lxLfXQOPNaa4gyp6MBhYWYvHabkuxlihUpPiADw21Ht20i87 ZOlg== X-Gm-Message-State: AOUpUlGrSC7DX6zhWq8yKJZmo2CndK7dGZOBWAUReAJAnjhVsBx+ZTmO 5+/scqRS7c68+o1sFTzrqMs6j9qqhi0hyfED6p8= X-Google-Smtp-Source: AA+uWPxTPr1Kz2juxLCEZj95Y2KxSTAEw/GFgZXTtLsgEIT9jJbvWyyKysM6kxG8DH5IWvlHnGZz0tDDU5s55QzzHT4= X-Received: by 2002:a5e:c017:: with SMTP id u23-v6mr4134421iol.155.1533244794902; Thu, 02 Aug 2018 14:19:54 -0700 (PDT) MIME-Version: 1.0 References: <20180801040712.13792-1-3chas3@gmail.com> <039ED4275CED7440929022BC67E706115326261E@SHSMSX103.ccr.corp.intel.com> <039ED4275CED7440929022BC67E7061153262AC1@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <039ED4275CED7440929022BC67E7061153262AC1@SHSMSX103.ccr.corp.intel.com> From: Chas Williams <3chas3@gmail.com> Date: Thu, 2 Aug 2018 17:19:43 -0400 Message-ID: To: "Zhang, Qi Z" Cc: dev@dpdk.org, beilei.xing@intel.com, Chas Williams Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] net/i40e: stop lldp before setting local lldp MIB X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 21:19:55 -0000 On Wed, Aug 1, 2018 at 10:16 PM Zhang, Qi Z wrote: > > > > > *From:* Chas Williams [mailto:3chas3@gmail.com] > *Sent:* Wednesday, August 1, 2018 11:31 PM > *To:* Zhang, Qi Z > *Cc:* dev@dpdk.org; Xing, Beilei ; Chas Williams < > chas3@att.com> > *Subject:* Re: [PATCH] net/i40e: stop lldp before setting local lldp MIB > > > > > > On Wed, Aug 1, 2018 at 10:00 AM Zhang, Qi Z wrote: > > Hi Williams: > > > -----Original Message----- > > From: Chas Williams [mailto:3chas3@gmail.com] > > Sent: Wednesday, August 1, 2018 12:07 PM > > To: dev@dpdk.org > > Cc: Xing, Beilei ; Zhang, Qi Z < > qi.z.zhang@intel.com>; > > Charles (Chas) Williams > > Subject: [PATCH] net/i40e: stop lldp before setting local lldp MIB > > > > From: "Charles (Chas) Williams" > > > > From the Intel Ethernet Controller X710/XXV710/XL710 Specifiction > > Update: > > > > Starting from NVM 5.02, if the Set Local LLDP MIB command is > > received while the DCBx specific agent is stopped, the command > > returns an EPERM error. If the command is received while the > > LLDP agent is stopped, it sets the local MIB without exchanging > > LLDP with peer, and returns SUCCESS. > > > > This results in the harmless, but annoying, diagnostic: > > > > default dcb config fails. err =3D -53, aq_err =3D 1. > > > > So, always stop the lldp daemon when we are in software mode before we > > attempt to call i40e_set_dcb_config. > > > > Signed-off-by: Chas Williams > > --- > > drivers/net/i40e/i40e_ethdev.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/net/i40e/i40e_ethdev.c > b/drivers/net/i40e/i40e_ethdev.c > > index a340540ef..03bedf5c1 100644 > > --- a/drivers/net/i40e/i40e_ethdev.c > > +++ b/drivers/net/i40e/i40e_ethdev.c > > @@ -11237,6 +11237,7 @@ i40e_dcb_init_configure(struct rte_eth_dev > > *dev, bool sw_dcb) > > * i40e_init_dcb we expect is failure with I40E_AQ_RC_EPE= RM > > * adminq status. Otherwise, it should return success. > > */ > > + i40e_aq_stop_lldp(hw, TRUE, NULL); > > I40e_aq_stop_lldp is intended to be removed with below two patches. > > commit c6431c891d9e9691e3205fe5c5350071cbaeb852 > commit fcbd40d4327b36725c4de9f33f57809edc359f4a > > > > Yeah about that. The i40e driver seems to go out of its way to program > the flow > > control outside of LLDP see i40e_update_flow_control() > and i40e_flow_ctrl_set(). > > So it's not clear to me what is going on here with DPDK and LLDP. Do you > really > > want LLDP running in this mode? The other branch > in i40e_dcb_init_configure() > > explicitly starts LLDP, so I assume at some point, LLDP wasn't/isn't > running. How did > > it get this way? With respect to item #70, shouldn't you therefore alway= s > start > > LLDP to workaround the bug? > > > > > > LLDP is enabled by firmware as default, from my view it is not necessary > to start LLDP, if We never stop it, and maybe we should not allow the ca= se > sw_dcb =3D TRUE since we can=E2=80=99t stop LLDP. > > > > Item#70 is fixed in later NVM's (6.01 or later). Perhaps a check to see > if the NVM > > is new enough to safely allow LLDP stopping? > > > > Yes, I agree, would you mind to add a firmware check for lldp_start and > lldp_stop in v2? So that fix your concern in the case with a new firmware > > For old firmware case, let=E2=80=99s just keep exist way , there should b= e some > re-work in future, and more test and review is required. > Yes, I can probably manage to add a firmware check. I will need a little bit to test it. One other question. What's up with i40e_update_flow_control()? Should this be called whenever the link state changes? Right now it only seems to be called when the device is started/initialized. > > > Thanks > > Qi > > > > > > > Regards. > Qi > > > > if ((ret =3D=3D I40E_SUCCESS) || (ret !=3D I40E_SUCCESS &= & > > hw->aq.asq_last_status =3D=3D I40E_AQ_RC_EPERM)) { > > memset(&hw->local_dcbx_config, 0, > > -- > > 2.14.4 > >