From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00068.outbound.protection.outlook.com [40.107.0.68]) by dpdk.org (Postfix) with ESMTP id 3C28B7D14 for ; Wed, 23 Aug 2017 21:44:46 +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=uvDt41QfG2vb4JpSqMJ0pSREqwQ8NDkNJ/GXm/YIJHE=; b=hVfu/7baJNeXeI6CIXvEh3EJ5fP0+X/IhFO8w80h05HyroirOKzqAj6W/KwCRkarYvl42WaDEiSncIdLPHjyk0RJVOcbnm2qm8bs4oLCj4+xPTyhPguooBYO2z2xdLMAQLpaMhG8aBr/0XunBAectWaCmPlHzUW0+8jVgxhC3qs= Received: from DB6PR0502MB3048.eurprd05.prod.outlook.com (10.172.250.136) by DB6PR0502MB2903.eurprd05.prod.outlook.com (10.172.249.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Wed, 23 Aug 2017 19:44:45 +0000 Received: from DB6PR0502MB3048.eurprd05.prod.outlook.com ([fe80::e938:efe9:effc:7ef8]) by DB6PR0502MB3048.eurprd05.prod.outlook.com ([fe80::e938:efe9:effc:7ef8%14]) with mapi id 15.01.1362.019; Wed, 23 Aug 2017 19:44:45 +0000 From: Matan Azrad To: =?iso-8859-1?Q?N=E9lio_Laranjeiro?= CC: Adrien Mazarguil , "dev@dpdk.org" Thread-Topic: [PATCH 1/2] net/mlx5: support device removal event Thread-Index: AQHTG/Pn/4WMHPqsCEaApbklMm5TxaKSOgnA Date: Wed, 23 Aug 2017 19:44:45 +0000 Message-ID: References: <1502627112-53405-1-git-send-email-matan@mellanox.com> <20170823094037.GS12995@autoinstall.dev.6wind.com> In-Reply-To: <20170823094037.GS12995@autoinstall.dev.6wind.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [85.64.136.190] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0502MB2903; 6:u7q0wys3HRrZ8zNOBLOQlm1UQSETYRCzHlPtThInerHld3k+q+fZ7GJXZ3fdmMZorF/DT1Vm9U/rAgHJ6YNx1itXep+Xp7JsAapUlzbYOdRNg7SNFnZ6tVWPBeufuzjR7IakggxITu2yegvkFuDFYVFYyTXrJkd/AWcrvhxLWdgKmwXxuMPypZ+l75RHvMI1y4YKphpXLfWLHeG4uZdsJ8kmF1JAjfYGwLVGzo+VXqm9rm/RjlbAYtT057NuXW/l+m+FDQmPMwLctJyLVzJ1T3wkfYY2G97nMMKKGFpELnWwCPNLWTDxk1VgzvLC8Qe1InIe3zGwXxW+IfTG/5gdlA==; 5:D3EATLj7ZqNNRm/N5wyiaeCKQohHYr5Aku121XbN5ZyKISj6IL1iyzn3+0X8XUnBkSZlKM/Q4m4eiXtn8TGq1EgdZnaxo2zmTe28D6enYerRFQeXPPZs7RTTmr83K7bofH9ZF8FdaxPrnVV4YPTuGg==; 24:5xIad4gT6JSps85LXPFU7RK4wicu+TGvhmoqZFngM69DAIU7YU58wpq1HrwYGROtxnJYw48FT2f+zrFaYMEa7l0MXqyFQ1LWP0TTo7GDZrs=; 7:wXQda4XENdNSYDy4GPiTfJjlLzTuMUp4gams1zSwxLAzItfsWzElCLXGt2aMx3O1fwG+LtlwckRKFU/M02yVSjc6lPUTPFM6VWIYsIHxIulLfY7xdaG6cpw26MDLA/BkJ7S0KQR3ScLJkun2N11Givhyno3xsALlXZyz92svt7YLIhBE5jemie0caS7TM1Yk2wWchknygDqOwi0PBIM2ZZOHuj9EiGIrsjATq5GrAv8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-ms-office365-filtering-correlation-id: 5fce7782-1aa7-4855-e8e0-08d4ea5f67fa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603188)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0502MB2903; x-ms-traffictypediagnostic: DB6PR0502MB2903: x-exchange-antispam-report-test: UriScan:(788757137089); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0502MB2903; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0502MB2903; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(24454002)(377454003)(189002)(199003)(13464003)(68736007)(81166006)(81156014)(74316002)(3280700002)(55016002)(8676002)(86362001)(3660700001)(101416001)(8936002)(53546010)(66066001)(189998001)(50986999)(305945005)(33656002)(54356999)(6916009)(76176999)(5250100002)(229853002)(7736002)(478600001)(14454004)(2950100002)(6436002)(7696004)(6506006)(97736004)(3846002)(5660300001)(105586002)(102836003)(6246003)(2900100001)(6116002)(110136004)(9686003)(99286003)(2906002)(106356001)(25786009)(4326008)(54906002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0502MB2903; H:DB6PR0502MB3048.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) 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-originalarrivaltime: 23 Aug 2017 19:44:45.1497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0502MB2903 Subject: Re: [dpdk-dev] [PATCH 1/2] net/mlx5: support device removal event 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, 23 Aug 2017 19:44:47 -0000 Hi Nelio > -----Original Message----- > From: N=E9lio Laranjeiro [mailto:nelio.laranjeiro@6wind.com] > Sent: Wednesday, August 23, 2017 12:41 PM > To: Matan Azrad > Cc: Adrien Mazarguil ; dev@dpdk.org > Subject: Re: [PATCH 1/2] net/mlx5: support device removal event >=20 > Hi Matan, >=20 > On Sun, Aug 13, 2017 at 03:25:11PM +0300, Matan Azrad wrote: > > Extend the LSC event handling to support the device removal as well. > > The Verbs library may send several related events, which are different > > from LSC event. > > > > The mlx5 event handling has been made capable of receiving and > > signaling several event types at once. > > > > This support includes next: > > 1. Removal event detection according to the user configuration. > > 2. Calling to all registered mlx5 removal callbacks. > > 3. Capabilities extension to include removal interrupt handling. > > > > Signed-off-by: Matan Azrad > > --- > > drivers/net/mlx5/mlx5.c | 2 +- > > drivers/net/mlx5/mlx5_ethdev.c | 100 > > +++++++++++++++++++++++++++-------------- > > 2 files changed, 68 insertions(+), 34 deletions(-) > > > > Hi > > This patch based on top of last Nelio mlx5 cleanup patches. > > > > diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c index > > bd66a7c..1a3d7f1 100644 > > --- a/drivers/net/mlx5/mlx5.c > > +++ b/drivers/net/mlx5/mlx5.c > > @@ -865,7 +865,7 @@ static struct rte_pci_driver mlx5_driver =3D { > > }, > > .id_table =3D mlx5_pci_id_map, > > .probe =3D mlx5_pci_probe, > > - .drv_flags =3D RTE_PCI_DRV_INTR_LSC, > > + .drv_flags =3D RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_INTR_RMV, > > }; > > > > /** > > diff --git a/drivers/net/mlx5/mlx5_ethdev.c > > b/drivers/net/mlx5/mlx5_ethdev.c index 57f6237..404d8f4 100644 > > --- a/drivers/net/mlx5/mlx5_ethdev.c > > +++ b/drivers/net/mlx5/mlx5_ethdev.c > > @@ -1112,47 +1112,75 @@ mlx5_ibv_device_to_pci_addr(const struct > > ibv_device *device, } > > > > /** > > - * Link status handler. > > + * Update the link status. > > + * Set alarm if the device link status is inconsistent. >=20 > Adding such comment should also comment about the issue this alarm is > solving i.e. why the link is inconsistent and why the alarm help to fix t= he > issue. >=20 I didn't see any comments about that in the old code , Hence I didn't write= it. I think you right and this could be added.(even before this patch). > > * > > * @param priv > > * Pointer to private structure. > > - * @param dev > > - * Pointer to the rte_eth_dev structure. > > * > > * @return > > - * Nonzero if the callback process can be called immediately. > > + * Zero if alarm is not set and the link status is consistent. > > */ > > static int > > -priv_dev_link_status_handler(struct priv *priv, struct rte_eth_dev > > *dev) > > +priv_link_status_alarm_update(struct priv *priv) > =09 > The old name is more accurate, the fact we need to program an alarm is a > work around to get the correct status from ethtool. If it was possible t= o avoid > it, this alarm would not exists. >=20 Probably because of the git +- format and this specific patch you got confu= se here. Actually priv_link_status_alarm_update function is a new function and don't= replace priv_dev_link_status_handler function. The new name is priv_dev_status_handler since now it is not just a link but also remove handler. (maybe more interrupt types in the future) > > +{ > > + struct rte_eth_link *link =3D &priv->dev->data->dev_link; > > + > > + mlx5_link_update(priv->dev, 0); > > + if (((link->link_speed =3D=3D 0) && link->link_status) || > > + ((link->link_speed !=3D 0) && !link->link_status)) { > > + if (!priv->pending_alarm) { > > + /* Inconsistent status, check again later. */ > > + priv->pending_alarm =3D 1; > > + rte_eal_alarm_set(MLX5_ALARM_TIMEOUT_US, > > + mlx5_dev_link_status_handler, > > + priv->dev); > > + } > > + return 1; > > + } else if (unlikely(priv->pending_alarm)) { > > + /* In case of link interrupt while link alarm was setting. */ > > + priv->pending_alarm =3D 0; > > + rte_eal_alarm_cancel(mlx5_dev_link_status_handler, priv- > >dev); > > + } > > + return 0; > > +} > > + > >[...] > > > > @@ -1172,11 +1200,11 @@ mlx5_dev_link_status_handler(void *arg) > > priv_lock(priv); > > assert(priv->pending_alarm =3D=3D 1); > > priv->pending_alarm =3D 0; > > - ret =3D priv_dev_link_status_handler(priv, dev); > > + ret =3D priv_link_status_alarm_update(priv); >=20 > It is not clear, this calls an alarm_update without getting the link stat= us, the > function name is "link_status_handler" why does the behavior does not > reflect the function name? >=20 > It is too confusing to be integrated as is, we had several bugs in this p= art of > the code, keep it clear, by keeping the old functions name. >=20 Just to explain what was changed in link functions: priv_dev_link_status_handler name changed=20 to priv_dev_status_handler as I already explained. Some of priv_dev_status_handler code was passed to new function named priv_link_status_alarm_update. This function updates the link status and sets\removes the inconsistency link alarm if needed. So, it updates the link status and the alarm setting. I open for other name suggestions :) I did this because I think the alarm handler(mlx5_dev_link_status_handler) shouldn't call to priv_dev_status_handler for trying to update the link again since: 1.We can't know who is calling (the interrupt or alarm) and the logic is di= fferent accordingly: In case of interrupt we must to update the link only when the interrupt typ= e is LCS. In case of alarm we always should call to link update. 2. It doesn't need to read new events from Verbs(it is not new interrupt). Therefore, the alarm handler just calls to the new function. So, the new function called ether by priv_dev_status_handler=20 in case of LCS interrupt or by mlx5_dev_link_status_handler for another chance to get consistent link status. > Thanks, >=20 > -- > N=E9lio Laranjeiro > 6WIND Regards Matan Azrad