Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2491572pxj; Mon, 31 May 2021 03:38:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRsCl5xg+C5qckDZNJmm7pS+MsmG8BTPB79Y2l8Ikq9jy56s3lF5WTiB4t3m209siHCzI/ X-Received: by 2002:a17:907:9612:: with SMTP id gb18mr22117342ejc.408.1622457517592; Mon, 31 May 2021 03:38:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622457517; cv=none; d=google.com; s=arc-20160816; b=mxSn7fzPBRMTVIFApNCRLc3tEd++plHoKKl2zqbW2t4x/wkgGR+myZbF4MtDJXRqIm divUHQjqUP6Kz3iui/60lJjB2yHUI0M18+615SMG13rNnTWXlqJ17o0sw+E8JPnANjvm zwCwjZ6VaRZ+U+O908KlvzBl+mIEBNInFkuEtqLuRA71+0K2yK8nU4P6Ms4X4SvT6I2Z lCBz5mpxYPoIETzXY9ZcUNYKUx5l3vHFAVBn9hpN4xKpK8qiLtj7to2Fk7g3bz5vPpXg 2XUdSTcdBymTdVm5AdLKGHrqofJpEKfOfO4zxC+QzvRVRwbH/y2Nwy4pNh897dgfloZj zQ2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=ztvaQAcyeZIIjZ4FmefgbFwUkshhJ4kskyysQqlutkQ=; b=w+lcL96IN+ricGZhnLwA5cBEKimzGsf8HRbkfuEaC70p1CEY+y5ZdpPzmdzAxyG++6 96UYNqwh9mqvcwPtRsZzLAEXSimkJikDw7MPioZA9U/d+MagvMHauGduLt/xseB10Qho oj70WjMsWjjKZx5l58mC2611yz7ol2lt39sv/Tnne0yAZ6e4oGfyQNCXxqi6vrzrT6j6 /CYTlNUn8ONi+ZE501o6MCrvpOXxFc7YVVZRWd6P9hUzZ/GnJVvzFEU+9nNkpsSLER0r 7aK4dse91EaJN0AyezAKyRVhBXqcIOhWocsg6wBLwne55UFOauuBiUyjjj0f/pWcRH7J 7xQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si14607850eji.591.2021.05.31.03.38.14; Mon, 31 May 2021 03:38:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231338AbhEaKiO (ORCPT + 99 others); Mon, 31 May 2021 06:38:14 -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. >