All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yunsheng Lin <linyunsheng@huawei.com>
To: Parav Pandit <parav@nvidia.com>, Jakub Kicinski <kuba@kernel.org>
Cc: moyufeng <moyufeng@huawei.com>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Jiri Pirko <jiri@resnulli.us>, Or Gerlitz <gerlitz.or@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"michal.lkml@markovi.net" <michal.lkml@markovi.net>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	Jiri Pirko <jiri@nvidia.com>,
	Salil Mehta <salil.mehta@huawei.com>,
	"lipeng (Y)" <lipeng321@huawei.com>,
	Guangbin Huang <huangguangbin2@huawei.com>,
	"shenjian15@huawei.com" <shenjian15@huawei.com>,
	"chenhao (DY)" <chenhao288@hisilicon.com>,
	Jiaran Zhang <zhangjiaran@huawei.com>,
	"linuxarm@openeuler.org" <linuxarm@openeuler.org>
Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension
Date: Wed, 9 Jun 2021 19:05:23 +0800	[thread overview]
Message-ID: <d54ae715-8634-c983-1602-8cd8dea2a5e2@huawei.com> (raw)
In-Reply-To: <DM8PR12MB54802CA9A47F1585DC3347A5DC369@DM8PR12MB5480.namprd12.prod.outlook.com>

On 2021/6/9 17:38, Parav Pandit wrote:
> 
>> From: Yunsheng Lin <linyunsheng@huawei.com>
>> 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?

> 


  reply	other threads:[~2021-06-09 11:05 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01  5:37 [RFC net-next 0/8] Introducing subdev bus and devlink extension Parav Pandit
2019-03-01  5:37 ` [RFC net-next 1/8] subdev: Introducing subdev bus Parav Pandit
2019-03-01  7:17   ` Greg KH
2019-03-01 16:35     ` Parav Pandit
2019-03-01 17:00       ` Greg KH
2019-03-26 11:48     ` Lorenzo Pieralisi
2019-03-01  5:37 ` [RFC net-next 2/8] subdev: Introduce pm callbacks Parav Pandit
2019-03-01  5:37 ` [RFC net-next 3/8] modpost: Add support for subdev device id table Parav Pandit
2019-03-01  5:37 ` [RFC net-next 4/8] devlink: Introduce and use devlink_init/cleanup() in alloc/free Parav Pandit
2019-03-01  5:37 ` [RFC net-next 5/8] devlink: Add variant of devlink_register/unregister Parav Pandit
2019-03-01  5:37 ` [RFC net-next 6/8] devlink: Add support for devlink subdev lifecycle Parav Pandit
2019-03-01  5:37 ` [RFC net-next 7/8] net/mlx5: Add devlink subdev life cycle command support Parav Pandit
2019-03-01  7:18   ` Greg KH
2019-03-01 16:04     ` Parav Pandit
2019-03-01  5:37 ` [RFC net-next 8/8] net/mlx5: Add subdev driver to bind to subdev devices Parav Pandit
2019-03-01  7:21   ` Greg KH
2019-03-01 17:21     ` Parav Pandit
2019-03-05  7:13       ` Greg KH
2019-03-05 17:57         ` Parav Pandit
2019-03-05 19:27           ` Greg KH
2019-03-05 21:37             ` Parav Pandit
2019-03-01 22:12   ` Saeed Mahameed
2019-03-04 16:45     ` Parav Pandit
2019-03-01 20:03 ` [RFC net-next 0/8] Introducing subdev bus and devlink extension Jakub Kicinski
2019-03-04  4:41   ` Parav Pandit
2019-03-05  1:35     ` Jakub Kicinski
2019-03-05 19:46       ` Parav Pandit
2019-03-05 22:39         ` Kirti Wankhede
2019-03-05 23:17           ` Parav Pandit
2019-03-05 23:44             ` Parav Pandit
2019-03-06  0:44               ` Parav Pandit
2019-03-06  3:51                 ` Kirti Wankhede
2019-03-06  5:42                   ` Parav Pandit
2019-03-07 19:04                     ` Kirti Wankhede
2019-03-07 20:27                       ` Parav Pandit
2019-03-07 20:53                         ` Kirti Wankhede
2019-03-07 21:02                           ` Parav Pandit
2019-03-07 21:07                             ` Kirti Wankhede
2019-03-07 21:21                               ` Parav Pandit
2019-03-07 22:01                                 ` Kirti Wankhede
2019-03-07 22:31                                   ` Parav Pandit
2019-03-08 12:19                                     ` Kirti Wankhede
2019-03-08 17:09                                       ` Parav Pandit
2019-03-05  1:45     ` Jakub Kicinski
2019-03-05 16:52       ` Parav Pandit
2021-05-31 10:36         ` moyufeng
2021-06-01  5:37           ` Jakub Kicinski
2021-06-01  7:33             ` Yunsheng Lin
2021-06-01 21:34               ` Jakub Kicinski
2021-06-02  2:24                 ` Yunsheng Lin
2021-06-02 16:34                   ` Jakub Kicinski
2021-06-03  3:46                     ` Yunsheng Lin
2021-06-03 17:53                       ` Jakub Kicinski
2021-06-04  1:18                         ` Yunsheng Lin
2021-06-04 18:41                           ` Jakub Kicinski
2021-06-07  1:36                             ` Yunsheng Lin
2021-06-07 19:46                               ` Jakub Kicinski
2021-06-08 12:10                                 ` Yunsheng Lin
2021-06-08 17:29                                   ` Jakub Kicinski
2021-06-09  9:16                                     ` Yunsheng Lin
2021-06-09  9:38                                       ` Parav Pandit
2021-06-09 11:05                                         ` Yunsheng Lin [this message]
2021-06-09 11:59                                           ` Parav Pandit
2021-06-09 12:30                                             ` Yunsheng Lin
2021-06-09 13:45                                               ` Parav Pandit
2021-06-10  7:04                                                 ` Yunsheng Lin
2021-06-10  7:17                                                   ` Parav Pandit
2021-06-09 16:40                                       ` Jakub Kicinski
2021-06-10  6:52                                         ` Yunsheng Lin
2021-06-09  9:52                                   ` Parav Pandit
2021-06-09 11:16                                     ` Yunsheng Lin
2021-06-09 12:00                                       ` Parav Pandit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d54ae715-8634-c983-1602-8cd8dea2a5e2@huawei.com \
    --to=linyunsheng@huawei.com \
    --cc=chenhao288@hisilicon.com \
    --cc=davem@davemloft.net \
    --cc=gerlitz.or@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=huangguangbin2@huawei.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=jiri@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@openeuler.org \
    --cc=lipeng321@huawei.com \
    --cc=michal.lkml@markovi.net \
    --cc=moyufeng@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=parav@nvidia.com \
    --cc=salil.mehta@huawei.com \
    --cc=shenjian15@huawei.com \
    --cc=zhangjiaran@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.