From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0083.outbound.protection.outlook.com [104.47.0.83]) by dpdk.org (Postfix) with ESMTP id 878273195 for ; Sat, 20 Jan 2018 20:04:23 +0100 (CET) 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=mmx5rOVqfRdVCwpabF1qw998NYxYbC50XWSJ9r2DAFA=; b=ESJOafdDR1kM3S7Q9t7mDjQKBX3sNt4wWmr9T6oNEPRE2FUAOuIpCUvmL3iw+rf00TFMqEy7+nHCkNjgqk+OB169hnKuVKC0cuJBRj2hrJdPLgYpFdMHWrxgoRbQEGp4m3Q8qPJbZDPSflsaa54eeIso9ATLsrXTBi5pHb8jlMs= Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com (52.133.21.26) by AM6PR0502MB3733.eurprd05.prod.outlook.com (52.133.21.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Sat, 20 Jan 2018 19:04:21 +0000 Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com ([fe80::6c28:c6b3:de94:a733]) by AM6PR0502MB3797.eurprd05.prod.outlook.com ([fe80::6c28:c6b3:de94:a733%13]) with mapi id 15.20.0428.019; Sat, 20 Jan 2018 19:04:21 +0000 From: Matan Azrad To: Thomas Monjalon , Ferruh Yigit , "Ananyev, Konstantin" CC: "dev@dpdk.org" , Adrien Mazarguil , Gaetan Rivet , "Andrew Rybchenko" , Alejandro Lucero , Jerin Jacob , Hemant Agrawal , Shahaf Shuler , Olivier MATZ , "Zhang, Helin" Thread-Topic: [dpdk-dev] [PATCH v6 4/6] ethdev: adjust APIs removal error report Thread-Index: AQHTkIIfz/9AsEWLtE+XPWGUXf0Nn6N57D0QgAF1TICAABqAAIAABWkAgAAA6YCAAZYf8A== Date: Sat, 20 Jan 2018 19:04:21 +0000 Message-ID: References: <1516220357-13013-1-git-send-email-matan@mellanox.com> <3568963.dcr6cRumit@xps> <7d77f38b-1259-d4b8-9d19-a21d80de9c04@intel.com> <3230393.d19WHEAjBn@xps> In-Reply-To: <3230393.d19WHEAjBn@xps> 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; AM6PR0502MB3733; 7:oc/EtHhxoetII+MsGqEoQuqsQ6VQuD0CyjR+MhiHTFuAEarsjnrQAMGwpLbZ+GnQ/36bQnzIK+aZUN5U/lLAOlppUFBz0P0JJD8d+QN4XWtIvqtcgbknPwrbTulsaqNce53LMiHlHEujhqm3Zxigx6JAFHwcNUkBUDw2h1EPF9LIksBIoEwgInGDKqrpB6eDmhCeb5wcFJhA/ZpieMpE3eLE256twdlgBRu2R940i9gqSb51p3OlAXfhSYt5tqpG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2e765461-3450-48b4-bc06-08d560389d61 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM6PR0502MB3733; x-ms-traffictypediagnostic: AM6PR0502MB3733: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:AM6PR0502MB3733; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM6PR0502MB3733; x-forefront-prvs: 0558D3C5AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(39860400002)(376002)(346002)(366004)(189003)(199004)(53754006)(76104003)(7736002)(7416002)(305945005)(54906003)(66066001)(478600001)(110136005)(68736007)(5660300001)(2906002)(97736004)(26005)(86362001)(39060400002)(229853002)(5250100002)(8656006)(6246003)(74316002)(2950100002)(4326008)(9686003)(6436002)(2900100001)(55016002)(3846002)(316002)(33656002)(106356001)(105586002)(3660700001)(3280700002)(99286004)(8936002)(81166006)(6116002)(53936002)(25786009)(7696005)(14454004)(93886005)(8676002)(81156014)(53546011)(6506007)(102836004)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0502MB3733; H:AM6PR0502MB3797.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) x-microsoft-antispam-message-info: rsguSNccYW30O74PbE2gpifA3/FKauoL+ace0mSKHwOEYdEhmhfbBVd60EHi72K89xSUN5TspZtI3/g1b6P0jw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e765461-3450-48b4-bc06-08d560389d61 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 19:04:21.6718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0502MB3733 Subject: Re: [dpdk-dev] [PATCH v6 4/6] ethdev: adjust APIs removal error report 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: Sat, 20 Jan 2018 19:04:23 -0000 Hi all From: Thomas Monjalon, Friday, January 19, 2018 8:17 PM > 19/01/2018 19:13, Ferruh Yigit: > > On 1/19/2018 5:54 PM, Thomas Monjalon wrote: > > > 19/01/2018 17:19, Ferruh Yigit: > > >> On 1/18/2018 6:10 PM, Matan Azrad wrote: > > >>> From: Ferruh Yigit, Thursday, January 18, 2018 7:31 PM > > >>>> This patch updates *all* ethdev public APIs to add if device is > > >>>> removed check? > > >>> > > >>> Yes. > > >>> > > >>>> And each check goes to ethdev is_removed() dev_ops to ask if dev > > >>>> is removed. > > >>> Probably, if the REMOVED state setted in will not call device > is_remove. > > >>> > > >>>> These must be better way of doing this, am I missing something. > > >>> > > >>> Suggest. > > >> > > >> With a silly analogy, this is like a blind person asking each time > > >> if he is dead before talking to other person. Just to accurate the analogy:) This is like a blind person(application,ethdev) using its guide dog(ethdev = device), every time the dog refuses to take action (error occurred), the bl= ind person asks if the dog can be a guide dog anymore(removal error).=20 > > >> At first glance I can think of a kind of watchdog timer can be > > >> implemented in ethdev layer. It provides periodic checks and if > > >> device is dead it calls the registered user callback function. > > >> > > >> This method presented as synchronous method but not triggered from > > >> side where event happens, I mean not triggered from PMD but from > application. > > >> So does application doing polling continuously if device is dead? > > >> Or if application is relying this patch to add a check in each API, > > >> what happens if device removed during data processing, will app rely= on > asynchronous method? > > > > > > We cannot put a mutex on hardware removal :) So we have to live with > > > errors du to removal. > > > If we are trying to configure a removed device, the error will be > > > not related to the root cause. > > > This patch is just trying to improve the situation by returning an > > > appropriate error code if removal can be detected. > > > Note: the check is run only if there is an error and if the removal > > > is not already detected. > > > > > > If I understand well, you prefer relying only on asynchronous > > > hotplug events? Even if they come really late? > > > > I think asynchronous hotplug events are better approach, but if they > > are late I understand you need a solution. > > > > I assume issue is when device is removed, application can make API > > calls until it detects the removal. > > > > For that case what do you think instead of ethdev abstraction layer > > doing a translation, define a specific error type and return it from > > PMDs to indicate that error is related to the missing device and > > application will know device is no more there? And consistently use tha= t > error type in all PMDs. >=20 > Yes it is also a good solution. > I think Matan proposed to integrate it in ethdev to avoid duplicating the > same mechanism in every PMDs. >=20 Yes, as a lot of ethdev API code pieces do. > > Or what do you think above suggested flexible watchdog timer > > implementation in ethdev, so applications may be informed about missing > device faster. >=20 > I think the watchdog would compete with hotplug events. > So I prefer not integrating one more asynchronous mechanism for the same > purpose. > If we want polling, it can be an option to enable in EAL hotplug. Konstantin wrote in another thread: >+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0); >+ >+ dev =3D &rte_eth_devices[port_id]; >+ >+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->is_removed, 0); > I'd says these 2 checks have to be swapped. Konstantin, Please explain why.