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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24E44C4361B for ; Thu, 17 Dec 2020 00:09:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DB73A23772 for ; Thu, 17 Dec 2020 00:09:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730878AbgLQAJc (ORCPT ); Wed, 16 Dec 2020 19:09:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:36684 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729023AbgLQAJc (ORCPT ); Wed, 16 Dec 2020 19:09:32 -0500 Date: Wed, 16 Dec 2020 16:08:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608163731; bh=g801CA1mP6r8B24edAn5HCOD7wX68sdbO7aF1eAwbMs=; h=From:To:Cc:Subject:In-Reply-To:References:From; b=a8mnTHoLnYVS/FWf0dLopw1Dth2zfC1Pfx8NxFC7qlZ5kge18lx+OMb5pWDlKiU8N wivCZTyYQ7zeeg8beWlyL3vwdffC/+96fIxWM30vxorVUXyc2EQPKrvgk0lqTAat48 tPEfSbF7rUdH7xkANxCh1bE45sBS0GDXjaYsDExeD9Qo9MI/O3+b0XTiI3X9WMKDXY GPazBaUgq0gYN+GiELoE6ArrPEo1cEdwVGhHiszWuIuLBMOfMiTkrajjR9Q0D0jIWM boWSlujpfyudxGxqVRQ6AaCbGz7t3ygWjSJlrAKcEWViKyhxdnrUQwg/m3Kco33eSQ AOt1VueIwyvkw== From: Jakub Kicinski To: Parav Pandit Cc: Saeed Mahameed , "David S. Miller" , Jason Gunthorpe , Leon Romanovsky , "netdev@vger.kernel.org" , "linux-rdma@vger.kernel.org" , David Ahern , Jacob Keller , Sridhar Samudrala , "david.m.ertman@intel.com" , "dan.j.williams@intel.com" , "kiran.patil@intel.com" , "gregkh@linuxfoundation.org" , Jiri Pirko , Vu Pham , Saeed Mahameed Subject: Re: [net-next v5 05/15] devlink: Support get and set state of port function Message-ID: <20201216160850.78223a1a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20201215090358.240365-1-saeed@kernel.org> <20201215090358.240365-6-saeed@kernel.org> <20201215163747.4091ff61@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> 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 Wed, 16 Dec 2020 05:15:04 +0000 Parav Pandit wrote: > > From: Jakub Kicinski > > Sent: Wednesday, December 16, 2020 6:08 AM > > > > On Tue, 15 Dec 2020 01:03:48 -0800 Saeed Mahameed wrote: > > > From: Parav Pandit > > > > > > devlink port function can be in active or inactive state. > > > Allow users to get and set port function's state. > > > > > > When the port function it activated, its operational state may change > > > after a while when the device is created and driver binds to it. > > > Similarly on deactivation flow. > > > > So what's the flow device should implement? > > > > User requests deactivated, the device sends a notification to the driver > > bound to the device. What if the driver ignores it? > > > If driver ignores it, those devices are marked unusable for new allocation. > Device becomes usable only after it has act on the event. But the device remains fully operational? So if I'm an admin who wants to unplug a misbehaving "entity"[1] the deactivate is not gonna help me, it's just a graceful hint? Is there no need for a forceful shutdown? [1] refer to earlier email, IDK what entity is supposed to use this > > > + * @DEVLINK_PORT_FUNCTION_OPSTATE_DETACHED: Driver is detached > > from the function of port; it is > > > + * safe to delete the port. > > > + */ > > > +enum devlink_port_function_opstate { > > > + DEVLINK_PORT_FUNCTION_OPSTATE_DETACHED, > > > > The port function must be some Mellanox speak - for the second time - I > > have no idea what it means. Please use meaningful names. > > > It is not a Mellanox term. > Port function object is the one that represents function behind this port. > It is not a new term. Port function already exists in devlink whose operational state attribute is defined here. I must have missed that in review. PCI functions can host multiple ports. So "port function" does not compute for me. Can we drop the "function"?