From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40040.outbound.protection.outlook.com [40.107.4.40]) by dpdk.org (Postfix) with ESMTP id C8AB47CC0 for ; Thu, 24 Aug 2017 16:33:45 +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=S3MCmNXxqIc5Uj3nmJvbDEqRM5oGSpW0XoHjCmQsXvw=; b=yV8F+BXt8Af9uoArfX9cGM/djNiouE2moDTvNL4iJ8Bdw3u4bbfIGutesPPZwnh37E77H2cY6aSIkIqA6lVirXgfaES5RXcsMV8i6PzmtKEit+i5uHa1nWE+LiNN0kx4HgowRdysxu49iL54nUm7FByO+CASJah6qlKLMkZ9sXU= Received: from DB6PR0502MB3048.eurprd05.prod.outlook.com (10.172.250.136) by DB6PR0502MB2935.eurprd05.prod.outlook.com (10.172.249.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Thu, 24 Aug 2017 14:33:44 +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; Thu, 24 Aug 2017 14:33:44 +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/4WMHPqsCEaApbklMm5TxaKSOgnAgADl/gCAAGkHcA== Date: Thu, 24 Aug 2017 14:33:43 +0000 Message-ID: References: <1502627112-53405-1-git-send-email-matan@mellanox.com> <20170823094037.GS12995@autoinstall.dev.6wind.com> <20170824073824.GA4544@autoinstall.dev.6wind.com> In-Reply-To: <20170824073824.GA4544@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; DB6PR0502MB2935; 6:R+k/FOoTpEV4uM4kLTUf/dpj31Jp4ecBOCG+m1R9I/r3/Z9Znak3l81Pqjqrm/Zvbpv637bGsvGKzWpInsp2xwtpJHolrz2WGxTr363HKSW6z2l36U7OmhByiGXjAffIUXs+CSlKfZWBLF2QVoLNvZTVxZXmRy2snoKLpc+ChRiIuS92aPu8obDafygwxBVPo5X6QYIeY3JVOSWUfhfCmgfiy+35v0cvV7HFv1MhZ5GIL6kfmhpr1oRF+WUaeI+QDdrRGN/Rd9zpbEMsxsffsDaz0gBAWd3We+2U1Iy8smJDTKa+PgCAzsRtdYVp5Y23y8PjEIgco9JNcIhwuLkawA==; 5:nR3k5FtFEeVY3Wt1HDP9KybGabsk6RtS9p4YyrCXpGsQCwJdpsZFJQOzhFQekdMi7a9aLCI1VTpOQE/+s9aGCvpNLPiu3fzgrA46ubyckM5rP/WJwgUU2hmGTARX+4CoR1LpuxoteO1TPN8OtaGgvA==; 24:dF/Bu9vG/Bx0TK2Y9wFSIiBIbtQURmfcQe4V6kfSYfy4RTz0U3zNxygduvsFhI3K9ClcEUGaCCJg1PQvwCrUbnSAm8ekCvmsPAGPJeyDxIc=; 7:5jglFNidNGwF4/3z7uUxO+oVWJ4wOnz5NTAjHxjn6CkN8ZKMLTl5GYD4DE5IDgTdwSOh3R2aLRQw5fDW2IhYiMwI6DhY3iqoRALxV++G9r+Gn2Z5ULdh8Ggk9SytDbxJRipzmbj9p4Z9IT1l4xiXCUcPciIyYSkQHohE3KMqA2ITOgr2+bgIpnShuWqiwwZRfYD/IZlxclBL+v1XqkI+dT7ZIyXmj3zsNErfn8f/w7c= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-ms-office365-filtering-correlation-id: f0367cc1-002a-4bb2-a7f4-08d4eafd1f7f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0502MB2935; x-ms-traffictypediagnostic: DB6PR0502MB2935: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0502MB2935; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0502MB2935; x-forefront-prvs: 04097B7F7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(13464003)(199003)(189002)(377454003)(24454002)(3280700002)(2900100001)(2906002)(53936002)(6246003)(33656002)(50986999)(8936002)(3660700001)(25786009)(54906002)(189998001)(76176999)(55016002)(54356999)(7696004)(110136004)(97736004)(101416001)(66066001)(99286003)(4326008)(68736007)(5660300001)(9686003)(6436002)(478600001)(81156014)(106356001)(74316002)(6916009)(2950100002)(8676002)(102836003)(5250100002)(6506006)(105586002)(14454004)(81166006)(86362001)(6116002)(7736002)(305945005)(53546010)(3846002)(93886005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0502MB2935; H:DB6PR0502MB3048.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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: 24 Aug 2017 14:33:44.0136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0502MB2935 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: Thu, 24 Aug 2017 14:33:46 -0000 Hi Nelio > -----Original Message----- > From: N=E9lio Laranjeiro [mailto:nelio.laranjeiro@6wind.com] > Sent: Thursday, August 24, 2017 10:38 AM > To: Matan Azrad > Cc: Adrien Mazarguil ; dev@dpdk.org > Subject: Re: [PATCH 1/2] net/mlx5: support device removal event >=20 > On Wed, Aug 23, 2017 at 07:44:45PM +0000, Matan Azrad wrote: > > 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 > > > > > > Hi Matan, > > > > > > 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. > > > > > > 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 the issue. > > > > > I didn't see any comments about that in the old code , Hence I didn't w= rite > it. >=20 > Normal as the alarm is a work around specifically necessary to Mellanox P= MD. > Now you explicitly announce that this function program an alarm, the > question is why is it necessary? >=20 > > I think you right and this could be added.(even before this patch). >=20 > No, in the current code, it update the link, if it inconsistent it tries = to have a > link correct ASAP. There is no need to inform this function will program= an > alarm, it is internal cooking. >=20 > > > > * > > > > * @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) > > > > > > 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 to avoid it, this alarm would not exists. > > > > > Probably because of the git +- format and this specific patch you got > confuse here. >=20 > No I applied your patch and read your code. You did not understand my > comment. > I thought it because you said "old name" related to a new function name :)= =20 =20 > >[...] >=20 > When I read: >=20 > > void > > mlx5_dev_link_status_handler(void *arg) { > > struct rte_eth_dev *dev =3D arg; > > struct priv *priv =3D dev->data->dev_private; > > int ret; > > > > 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); > > priv_unlock(priv); > > - if (ret) > > + if (!ret) > > _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_L= SC, > NULL, > > - NULL); > > + NULL); > > } >=20 > I am expecting to find something related to a link update, what I see is = an > alarm update. I don't expect to update an alarm but a link. The names a= nd > action are inconsistent i.e. mlx5_dev_link_status_handler() should handle= a > link not an alarm. >=20 > I understand there is a need to add more function levels, but the > priv_link_status_alarm_update() should be renamed to something like > priv_link_status_update(). OK, I think I understand you. Because the alarm is a workaround you don't think it should be mentioned in function description or function name. (also the function subject should be the link status and not the alarm) I can agree with you about it. And I will create v2 with your suggestion - priv_link_status_update. The return value description can stay as in old code semantic: Zero if the callback process can be called immediately. Are you agree? Maybe we can tell something about the alarm and inconsistent reason In this function description or internal comment for future code review. If you want it, please suggest comment. Thank you. >=20 > Regards, >=20 > -- > N=E9lio Laranjeiro > 6WIND Regards Matan Azrad