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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 ECCE2C48BCF for ; Wed, 9 Jun 2021 11:05:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D0E95613B8 for ; Wed, 9 Jun 2021 11:05:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238318AbhFILHZ (ORCPT ); Wed, 9 Jun 2021 07:07:25 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:3921 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232165AbhFILHX (ORCPT ); Wed, 9 Jun 2021 07:07:23 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4G0PMK3jjTz6wr6; Wed, 9 Jun 2021 19:02:21 +0800 (CST) Received: from dggpemm500005.china.huawei.com (7.185.36.74) 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; Wed, 9 Jun 2021 19:05:25 +0800 Received: from [127.0.0.1] (10.69.30.204) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 9 Jun 2021 19:05:24 +0800 Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension To: Parav Pandit , Jakub Kicinski CC: moyufeng , Jakub Kicinski , Jiri Pirko , 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 , "shenjian15@huawei.com" , "chenhao (DY)" , Jiaran Zhang , "linuxarm@openeuler.org" References: <1551418672-12822-1-git-send-email-parav@mellanox.com> <20210531223711.19359b9a@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <7c591bad-75ed-75bc-5dac-e26bdde6e615@huawei.com> <20210601143451.4b042a94@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <20210602093440.15dc5713@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <857e7a19-1559-b929-fd15-05e8f38e9d45@huawei.com> <20210603105311.27bb0c4d@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <20210604114109.3a7ada85@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <4e7a41ed-3f4d-d55d-8302-df3bc42dedd4@huawei.com> <20210607124643.1bb1c6a1@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <530ff54c-3cee-0eb6-30b0-b607826f68cf@huawei.com> <20210608102945.3edff79a@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <2acd8373-b3dc-4920-1cbe-2b5ae29acb5b@huawei.com> From: Yunsheng Lin Message-ID: Date: Wed, 9 Jun 2021 19:05:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggeme713-chm.china.huawei.com (10.1.199.109) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/6/9 17:38, Parav Pandit wrote: > >> From: Yunsheng Lin >> Sent: Wednesday, June 9, 2021 2:46 PM >> > [..] > >>>> Is there any reason why VF use its own devlink instance? >>> >>> Primary use case for VFs is virtual environments where guest isn't >>> trusted, so tying the VF to the main devlink instance, over which >>> guest should have no control is counter productive. >> >> The security is mainly about VF using in container case, right? >> Because VF using in VM, it is different host, it means a different devlink >> instance for VF, so there is no security issue for VF using in VM case? >> But it might not be the case for VF using in container? > Devlink instance has net namespace attached to it controlled using devlink reload command. > So a VF devlink instance can be assigned to a container/process running in a specific net namespace. > > $ ip netns add n1 > $ devlink dev reload pci/0000:06:00.4 netns n1 > ^^^^^^^^^^^^^ > PCI VF/PF/SF. Could we create another devlink instance when the net namespace of devlink port instance is changed? It may seems we need to change the net namespace based on devlink port instance instead of devlink instance. This way container case seems be similiar to the VM case? > >> Also, there is a "switch_id" concept from jiri's example, which seems to be >> not implemented yet? > > switch_id is present for switch ports in [1] and documented in [2]. > > [1] /sys/class/net/representor_netdev/phys_switch_id. > [2] https://www.kernel.org/doc/Documentation/networking/switchdev.txt " Switch ID" Thanks for info. I suppose we could use "switch_id" to indentify a eswitch since "switch_id is present for switch ports"? Where does the "switch_id" of switch port come from? Is it from FW? Or the driver generated it? Is there any rule for "switch_id"? Or is it vendor specific? >