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=-5.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 04628C47082 for ; Mon, 31 May 2021 10:36:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D51DF60FF3 for ; Mon, 31 May 2021 10:36:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231292AbhEaKiS (ORCPT ); Mon, 31 May 2021 06:38:18 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:2480 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231280AbhEaKiC (ORCPT ); Mon, 31 May 2021 06:38:02 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Fts833qvtz67cd; Mon, 31 May 2021 18:33:23 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 31 May 2021 18:36:12 +0800 Received: from [10.67.103.6] (10.67.103.6) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 31 May 2021 18:36:12 +0800 Subject: Re: RE: [RFC net-next 0/8] Introducing subdev bus and devlink extension To: Jakub Kicinski , Jiri Pirko References: <1551418672-12822-1-git-send-email-parav@mellanox.com> <20190301120358.7970f0ad@cakuba.netronome.com> <20190304174551.2300b7bc@cakuba.netronome.com> CC: Parav Pandit , Or Gerlitz , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "michal.lkml@markovi.net" , "davem@davemloft.net" , "gregkh@linuxfoundation.org" , Jiri Pirko , Salil Mehta , "lipeng (Y)" , , Guangbin Huang , , , "chenhao (DY)" , Jiaran Zhang From: moyufeng Message-ID: <76785913-b1bf-f126-a41e-14cd0f922100@huawei.com> Date: Mon, 31 May 2021 18:36:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.103.6] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Jiri & Jakub Generally, a devlink instance is created for each PF/VF. This facilitates the query and configuration of the settings of each function. But if some common objects, like the health status of the entire ASIC, the data read by those instances will be duplicate. So I wonder do I just need to apply a public devlink instance for the entire ASIC to avoid reading the same data? If so, then I can't set parameters for each function individually. Or is there a better suggestion to implement it? Thanks! ~ On 2019/3/6 0:52, Parav Pandit wrote: > > >> -----Original Message----- >> From: Jakub Kicinski >> Sent: Monday, March 4, 2019 7:46 PM >> To: Parav Pandit >> Cc: Or Gerlitz ; netdev@vger.kernel.org; linux- >> kernel@vger.kernel.org; michal.lkml@markovi.net; davem@davemloft.net; >> gregkh@linuxfoundation.org; Jiri Pirko >> Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension >> >> On Mon, 4 Mar 2019 04:41:01 +0000, Parav Pandit wrote: >>>>> $ devlink dev show >>>>> pci/0000:05:00.0 >>>>> subdev/subdev0 >>>> >>>> Please don't spawn devlink instances. Devlink instance is supposed >>>> to represent an ASIC. If we start spawning them willy nilly for >>>> whatever software construct we want to model the clarity of the >>>> ontology will suffer a lot. >>> Devlink devices not restricted to ASIC even though today it is >>> representing ASIC for one vendor. Today for one ASIC, it already >>> presents multiple devlink devices (128 or more) for PF and VFs, two >>> PFs on same ASIC etc. VF is just a sub-device which is well defined by >>> PCISIG, whereas sub-device is not. Sub-device do consume actual ASIC >>> resources (just like PFs and VFs), Hence point-(6) of cover-letter >>> indicate that the devlink capability to tell how many such sub-devices >>> can be created. >>> >>> In above example, they are created for a given bus-device following >>> existing devlink construct. >> >> No, it's not "representing the ASIC for one vendor". It's how it works for >> switches (including mlxsw) and how it was described in the original cover >> letter: >> > Sorry for the confusion. > I meant to say, my understanding is Netronome creates one devlink instance for whole ASIC. > Please correct me if this is incorrect. > mlx5_core driver creates multiple devlink devices for PF and VFs for one ASIC. > >> Introduce devlink interface and first drivers to use it >> >> There a is need for some userspace API that would allow to expose things >> that are not directly related to any device class like net_device of >> ib_device, but rather chip-wide/switch-ASIC-wide stuff. >> >> [...] >> >> We can deviate from the original intent if need be and dilute the ontology. >> But let's be clear on the status quo, please. > Status quo is mlx5_core driver creates multiple devlink devices. It creates for devlink device for each PF and VF of a single ASIC. >