From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 959B398 for ; Wed, 25 Jul 2018 08:03:47 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2018 23:03:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,400,1526367600"; d="scan'208";a="218887078" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga004.jf.intel.com with ESMTP; 24 Jul 2018 23:03:42 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 24 Jul 2018 23:03:42 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 24 Jul 2018 23:03:42 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.100]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.173]) with mapi id 14.03.0319.002; Wed, 25 Jul 2018 14:02:47 +0800 From: "Zhang, Qi Z" To: "Wu, Yanglong" , "dev@dpdk.org" CC: "Wang, Dong1" Thread-Topic: [PATCH v2] net/ixgbe: fix link status when link is NACK Thread-Index: AQHUIyGSkfLYyrJZKEejK5DujpQVSaSfcm+g Date: Wed, 25 Jul 2018 06:02:46 +0000 Message-ID: <039ED4275CED7440929022BC67E706115325E9DE@SHSMSX103.ccr.corp.intel.com> References: <20180723030557.5815-1-yanglong.wu@intel.com> <20180724073032.33332-1-yanglong.wu@intel.com> In-Reply-To: <20180724073032.33332-1-yanglong.wu@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODNhOWI2YjgtOWJiMi00YTYxLWI4MDAtMTlkNGZkMTViOTQ4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidVdFYWRWb3FEQWcrUkNpOTlcL2lZK0ZhTHdYdDBXbXpYYjkrMENROGF1bXpsZ2p0bElLWWF3WnhPbjVxalV2clkifQ== x-ctpclassification: CTP_NT x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix link status when link is NACK 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: Wed, 25 Jul 2018 06:03:48 -0000 Hi Yanglang: > -----Original Message----- > From: Wu, Yanglong > Sent: Tuesday, July 24, 2018 3:31 PM > To: dev@dpdk.org > Cc: Zhang, Qi Z ; Wang, Dong1 > ; Wu, Yanglong > Subject: [PATCH v2] net/ixgbe: fix link status when link is NACK >=20 > Link status should be set as down when link is NACK. >=20 > Fixes: dc66e5fd01b9 ("net/ixgbe: improve link state check on VF") >=20 > Signed-off-by: Yanglong Wu >=20 > --- > v2: > no need to set link status again > --- > drivers/net/ixgbe/ixgbe_ethdev.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) >=20 > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > b/drivers/net/ixgbe/ixgbe_ethdev.c > index 997683d3b..3ffc72b40 100644 > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > @@ -3933,12 +3933,10 @@ ixgbevf_check_link(struct ixgbe_hw *hw, > ixgbe_link_speed *speed, > } >=20 > if (no_pflink_check) { > - if (*speed =3D=3D IXGBE_LINK_SPEED_UNKNOWN) > + if (*speed =3D=3D IXGBE_LINK_SPEED_UNKNOWN) { > mac->get_link_status =3D true; > - else > - mac->get_link_status =3D false; > - > - goto out; > + goto out; > + } > } Sorry, I can't understand this change combined with your commit log, could = you explain more? Btw, no_fplink_check =3D 1 means wait_to_complete =3D 0,=20 but in the case when *speed !=3D IXGBE_LINK_SPEED_UNKNOWN , you will still = go msg.read which I guess is not suppose be called in the case wait_to_comp= lete =3D 0, is it right? > /* if the read failed it could just be a mailbox collision, best wait > * until we are called again and don't report an error > -- > 2.11.0