From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DBA7C77B61 for ; Thu, 13 Apr 2023 16:55:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230268AbjDMQzV (ORCPT ); Thu, 13 Apr 2023 12:55:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230263AbjDMQzT (ORCPT ); Thu, 13 Apr 2023 12:55:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59E49AF05 for ; Thu, 13 Apr 2023 09:55:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C1C806402D for ; Thu, 13 Apr 2023 16:55:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 969DDC433D2; Thu, 13 Apr 2023 16:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681404910; bh=uQ20Q0istZfsKkpC4DDK2CNRL4QD/NsOy9NvZLeS+T4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mnzMTJOzNHz1HIgNr0bNv99bWRuIfIrYoUUYcT7vZ6wjwk+99d9o4/hbIYO0w0KGI zmG17TxPuEjVJ/bKB6cYzEmmqOEsJGkMNv+uk5FULvK1+iYuqEioG3gRFxnnw1Lf9R HHdnLOH+cqx6xrH6uNhsS8W6dv752uFPQFbetyQX9rsiXmKxoZrj9H+BqLiRRrqXUd OhHpSrfY1ZkX8zp0tFe3/rvQsqxMgiRpIeHBK9ldLS7eLV0CZPijZQFAcn9MXhAG/z HY+LmlUvYwCZDHd/bd7QGZYrwFNL5CdL9Ch9Z9C5rqGaPxwKJYRBo1xnyHr+oHAp2x EAUPn1JzsZPOA== Date: Thu, 13 Apr 2023 09:55:09 -0700 From: Jakub Kicinski To: Leon Romanovsky Cc: Shannon Nelson , brett.creeley@amd.com, davem@davemloft.net, netdev@vger.kernel.org, drivers@pensando.io, jiri@resnulli.us Subject: Re: [PATCH v9 net-next 13/14] pds_core: publish events to the clients Message-ID: <20230413095509.7f15e22c@kernel.org> In-Reply-To: <20230413164434.GT17993@unreal> References: <20230406234143.11318-1-shannon.nelson@amd.com> <20230406234143.11318-14-shannon.nelson@amd.com> <20230409171143.GH182481@unreal> <20230413085501.GH17993@unreal> <20230413081410.2cbaf2a2@kernel.org> <20230413164434.GT17993@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 13 Apr 2023 19:44:34 +0300 Leon Romanovsky wrote: > > > I don't think that it is safe behaviour from user POV. If FW resets > > > itself under the hood, how can client be sure that nothing changes > > > in its operation? Once FW reset occurs, it is much safer for the clients > > > to reconfigure everything. > > > > What's the argument exactly? We do have async resets including in mlx5, > > grep for enable_remote_dev_reset > > I think that it is different. I'm complaining that during FW reset, > auxiliary devices are not recreated and continue to be connected to > physical device with a hope that everything will continue to work from > kernel and FW perspective. > > It is different from enable_remote_dev_reset, where someone externally > resets device which will trigger mlx5_device_rescan() routine through > mlx5_unload_one->mlx5_load_one sequence. Hm, my memory may be incorrect and I didn't look at the code but I thought that knob came from the "hit-less upgrade" effort. And for "hit-less upgrade" not respawning the devices was the whole point. Which is not to disagree with you. What I'm trying to get at is that there are different types of reset which deserve different treatment.