From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0053.outbound.protection.outlook.com [104.47.0.53]) by dpdk.org (Postfix) with ESMTP id EAFB71B62D for ; Mon, 9 Apr 2018 14:28:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vEEpVTYlkJnM620AgGFuUFV9tYLChlEdloM9ADJnMXY=; b=lauBkaLeVc00u8uCe6+ZO+2qrHS6Wkef5aSCZ5H5mb7BU0NBdnCGGnLfNN8/aUABg/1Bv580RuTekG0j5Yh/AWC21o2SGVi47z/37EeSTN2bm4TpPVij1HREm0Mc2JFpBp4DByIXG3zuWzv44pF5Hj7jTMoFHB67/uyKPTbIrA8= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4506.eurprd05.prod.outlook.com (52.134.109.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Mon, 9 Apr 2018 12:28:04 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::808d:386e:26f3:859f]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::808d:386e:26f3:859f%13]) with mapi id 15.20.0653.014; Mon, 9 Apr 2018 12:28:04 +0000 From: Shahaf Shuler To: =?iso-8859-1?Q?N=E9lio_Laranjeiro?= CC: Adrien Mazarguil , Yongseok Koh , "dev@dpdk.org" Thread-Topic: [PATCH] net/mlx5: fix link status initialization Thread-Index: AQHTy+bChNPXB2fkBUSu8VuSnLilOaPwRWOwgAA+wYCAASMw0IAAFd8AgAUdLcCAAUcMAIAALUmg Date: Mon, 9 Apr 2018 12:28:04 +0000 Message-ID: References: <20180403044817.27457-1-shahafs@mellanox.com> <20180404073009.zgqu3yrj26trwdfr@laranjeiro-vm.dev.6wind.com> <20180404121051.ersiyf75gykwfon5@laranjeiro-vm.dev.6wind.com> <20180405065120.jqttkvlhjflpfdbj@laranjeiro-vm.dev.6wind.com> <20180409082736.spzxnp3bbcllakui@laranjeiro-vm.dev.6wind.com> In-Reply-To: <20180409082736.spzxnp3bbcllakui@laranjeiro-vm.dev.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB4506; 7:Jl+DF8MVA+LsdsNqV1gGkGr9QbQEjPd5G8cWqefPC2g3L6jpa8Qs5tKiL8+irMxXecAqolW7N43MsJihv5JKeiaQt53m6ScXBFBDpAiU/AVwQeAxcrcP/ZPXjQYkj8eRbARvv94S/cwuM6DMUbtuqI3fDV0Cq0uWcMbgbnRZ6ad/sxWVo6g+jpASH1kZqDe1Fc9Q4nf7ENV3gZlH7agxrbvxDuuXIyToyRb37kvGqbVAULA1H0sBHQyT5Y+Gvc79 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant X-MS-Office365-Filtering-Correlation-Id: 8c171851-f53c-4467-b9cb-08d59e1557aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4506; x-ms-traffictypediagnostic: DB7PR05MB4506: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:DB7PR05MB4506; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4506; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(366004)(346002)(39380400002)(189003)(199004)(6116002)(81156014)(7736002)(81166006)(3846002)(6436002)(5660300001)(54906003)(3660700001)(478600001)(305945005)(8936002)(6916009)(74316002)(9686003)(7696005)(33656002)(8676002)(25786009)(68736007)(229853002)(97736004)(5250100002)(105586002)(6506007)(3280700002)(55016002)(93886005)(106356001)(66066001)(2906002)(11346002)(476003)(4326008)(102836004)(486006)(2900100001)(99286004)(14454004)(6246003)(76176011)(446003)(26005)(316002)(53936002)(186003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4506; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: jGIeLD6Zs8BNOjSE430daBulLpqVOJ5625RWsKEycZ7J/PLn9vGppNAthOi/5nrj74RnJhHsglVX7CkHZSuUc7tONtwNvDXCvjlgmtrDmV0CnGm6i34IFbo92lXk8697pwZhplRBzjt0ewlMTGg3DSnYSOL9DNPQKo9KOB3ts+bHJLqm28Iz2IOjEIExTeAsXXMAXqcAhRsee1ritscOtg0FS/xwtnml4p2GZT+TLl3EvkG3yYsTZ5OQNVmjWWqG7YyiKol1HbSEAQi/E1GTU+qB4iTEE2U/95J6Oh2LEN1vmi8WRmYctZyG+uVjCr7ntGpB4rJKLd9PJ16rxptLVSC5+z6NBV8NmqYBYYwRYO5iqhQGeU+UW2LRLQ/Mu4WJEzUfnBghcQgBYVizyIQmrMdx2q7WxmLSrMjMI+DapYk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c171851-f53c-4467-b9cb-08d59e1557aa X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 12:28:04.4007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4506 Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix link status initialization 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: Mon, 09 Apr 2018 12:28:06 -0000 Monday, April 9, 2018 11:28 AM, N=E9lio Laranjeiro: > Subject: Re: [PATCH] net/mlx5: fix link status initialization >=20 > On Sun, Apr 08, 2018 at 01:09:27PM +0000, Shahaf Shuler wrote: > > Thursday, April 5, 2018 9:51 AM, N=E9lio Laranjeiro: > > > Subject: Re: [PATCH] net/mlx5: fix link status initialization > > > > > > On Thu, Apr 05, 2018 at 05:35:57AM +0000, Shahaf Shuler wrote: > > > > Wednesday, April 4, 2018 3:11 PM, N=E9lio Laranjeiro: > > > > > Subject: Re: [PATCH] net/mlx5: fix link status initialization > > > > > > > > > > On Wed, Apr 04, 2018 at 09:58:33AM +0000, Shahaf Shuler wrote: > > > > > > Wednesday, April 4, 2018 10:30 AM, N=E9lio Laranjeiro: > > > > > > > Subject: Re: [PATCH] net/mlx5: fix link status > > > > > > > initialization > > > > > > > > > > > > > > On Tue, Apr 03, 2018 at 07:48:17AM +0300, Shahaf Shuler wrote= : > > > > [..] > > > > > > > > > > > > According to your analysis, this is only necessary when the LCS > > > > > is configured in the device. Why not adding this call to > > > > > mlx5_dev_interrupt_handler_install() which is responsible to > > > > > install the LCS callback. > > > > > > > > I think it is good practice whether or not LSC is set. > > > > The link status should be initialized to the correct value after th= e probe. > > > > > > There is no guarantee the link will be accurate, at probe time the > > > link may be up so internal information has a status up with a speed w= ith > this patch. > > > The application probes a second port, in the mean time the link of > > > the first port goes down, the interrupt is still not installed and > > > the internal status becomes wrong (still up whereas the port is down)= . > > > > > > Finally at start, the device installs the handler, but the link is > > > still down whereas internally it is up, the application will call > > > rte_eth_link_get_nowait() which will directly copy the wrong > > > internal status to the application. > > > > This is not correct. > > Using Verbs, the async_fd on which link status interrupts are reported = is > created on probe. > > Even if the interrupt handler is not installed, interrupts still > > trigger on this fd. They will be processed when the interrupt handler > > will be installed as part of the port start. > > So in fact you have the whole trace on the link status changes waiting > > to be processed upon port start. >=20 > Right, but in such case, this patch still does not solves the issue. > Until the dev_start() is called, the link may be inconsistent with the re= al > status. >=20 > example: >=20 > pci_probe --> link is up. > leaving pci probe, the link goes downs --> internally the PMD has a link= up. >=20 > Until the dev_start() is called any call to rte_eth_link_get_nowait() wil= l copy > the internal PMD status which is not accurate. >=20 > From this point, the issue seems to fully come from > rte_eth_link_get_nowait() which should not make any copy until the port i= s > not started, until then the link may be inconsistent between the driver a= nd > the device. Right. However fixing it only on the ethdev layer is not enough. Assume the link was up from the beginning.=20 For the case were the call for rte_eth_link_get_nowait happens only after t= he port start, the link will still be wrong as it will be reported as down = (and no interrupt to fix it).=20 So to summarize I plan to have this patch (with modification of the wait_to= _complete) along with another fix for ethdev.=20 Do we have an agreement?=20 >=20 > Regards, >=20 > -- > N=E9lio Laranjeiro > 6WIND