public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Yanjun Zhu <yanjun.zhu@linux.dev>
To: Parav Pandit <parav@nvidia.com>,
	"dust.li@linux.alibaba.com" <dust.li@linux.alibaba.com>,
	Zhu Yanjun <yanjun.zhu@intel.com>, "jgg@ziepe.ca" <jgg@ziepe.ca>,
	"leon@kernel.org" <leon@kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH 0/3] RDMA net namespace
Date: Fri, 28 Oct 2022 11:49:27 +0800	[thread overview]
Message-ID: <e6115b24-811e-ff61-23d3-bc3e93a4d12c@linux.dev> (raw)
In-Reply-To: <PH0PR12MB548174B0CD9E7DA82DF9F25CDC329@PH0PR12MB5481.namprd12.prod.outlook.com>


在 2022/10/28 11:31, Parav Pandit 写道:
>> From: Yanjun Zhu <yanjun.zhu@linux.dev>
>> Sent: Thursday, October 27, 2022 11:21 PM
>>
>>
>> 在 2022/10/27 22:06, Parav Pandit 写道:
>>>> From: yanjun.zhu@linux.dev <yanjun.zhu@linux.dev>
>>>> Sent: Thursday, October 27, 2022 2:02 AM
>>>> To: Parav Pandit <parav@nvidia.com>; dust.li@linux.alibaba.com; Zhu
>>>> Yanjun <yanjun.zhu@intel.com>; jgg@ziepe.ca; leon@kernel.org; linux-
>>>> rdma@vger.kernel.org
>>>> Subject: Re: [PATCH 0/3] RDMA net namespace
>>>>
>>>> October 27, 2022 11:48 AM, "Parav Pandit" <parav@nvidia.com> wrote:
>>>>
>>>>>> From: yanjun.zhu@linux.dev <yanjun.zhu@linux.dev>
>>>>>> Sent: Wednesday, October 26, 2022 11:39 PM
>>>>>>
>>>>>> October 27, 2022 11:21 AM, "Parav Pandit" <parav@nvidia.com> wrote:
>>>>>>
>>>>>> From: yanjun.zhu@linux.dev <yanjun.zhu@linux.dev>
>>>>>> Sent: Wednesday, October 26, 2022 11:17 PM
>>>>>>
>>>>>> October 27, 2022 11:10 AM, "Parav Pandit" <parav@nvidia.com> wrote:
>>>>>>
>>>>>> From: yanjun.zhu@linux.dev <yanjun.zhu@linux.dev>
>>>>>> Sent: Wednesday, October 26, 2022 11:08 PM
>>>>>>
>>>>>> October 27, 2022 11:01 AM, "Parav Pandit" <parav@nvidia.com> wrote:
>>>>>>
>>>>>> From: Dust Li <dust.li@linux.alibaba.com>
>>>>>> Sent: Wednesday, October 26, 2022 10:31 PM
>>>>>>
>>>>>> 2. else we are in
>>>>>> exclusive mode. When the corresponding netdevice of the RoCE or
>>>>>> iWarp device is moved from one net namespace to another, we move
>>>>>> the
>>>> RDMA
>>>>>> device into that net namespace
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>> No. one device is not supposed to move other devices.
>>>>>> Every device is independent that should be moved by explicit
>> command.
>>>>>> Can you show us where we can find this rule "Every device is
>>>>>> independent that should be moved by explicit command."?
>>>>>>
>>>>>> Also changes like above breaks the existing orchestration, it no-go.
>>>>>>
>>>> And I do not find the rule that you mentioned.
>>>>
>>>>> There is no Linux kernel subsystem or module to my knowledge that
>>>>> attempt to move multiple devices using single command.
>>>>> When user executes command , user explicitly give device name "foo",
>>>> only "foo" should move.
>>>>> Other loosely coupled device whose name is not specified in the ip
>>>>> command which has a different life cycle should not move along with
>> "foo".
>>>>> You are trying to define the new rule that breaks the existing ABI
>>>>> and the iproute2 (ip and rdma) command semantics.
>>>>> It is implicit that when command is issued on device A, operate on
>>>>> device A. This is part of
>>>>> iproute2 functioning.
>>>> About iproute2, I read this link
>>>> https://wiki.linuxfoundation.org/networking/iproute2#documentation
>>>>
>>>> There is no rules that you mentioned.
>>>>
>>>> This rule is defined explicitly or implicitly?
>>>>
>>> Wiki pages links are not the documentation.
>>> Man pages of the iproute2 is documentation of iproute2 at [1] and [2].
>>>
>>> [1] https://man7.org/linux/man-pages/man8/rdma-system.8.html
>>> [2] https://man7.org/linux/man-pages/man8/rdma-dev.8.html
>>>
>>> As I explained, the explicit rule that you are looking for that say "when I
>> modify device foo, it can also modifies the device bar".
>>> Because no part of the Linux kernel does that usually, unless the device is
>> representor/control object etc or has parent/child relationship.
>>> It is fundamental to a command definition, not a matter of explicit or
>> implicit.
>>
>>   From the ABI, iproute2 and current rdma command links, I can not find the
>> rule that you mentioned.
>>
>> Can you tell me the exact link that make such definition?
>>
> I explained you already above. You are repeating your weird question.

You mentioned that it is a rule. I just want to know where it is defined.

>
> Can you show one iproute2 example, where you specify a command on device A, and kernel operates on device, A, P, Q, R?

When you add a net devices to a bonding device, you will find changes on 
the bonding device and the net devices.

Or some other commands like this.

Zhu Yanjun

> This is the attempt you are trying to do for unknown reasons.
>
> So, can you please explain, what is the problem in using existing rdma dev commands that move rdma device to net namespace?
>
>>> And clearly in this discussion foo and bar are loosely coupled network
>> devices, one is not controlling the other.
>>> Also, a rdma device is attached to multiple net devices, primary and other
>> upper devices such as vlan, macvlan etc.
>>
>> To a RoCE device, how to attach a rdma device to vlan, macvlan?
>>
>> To "a rdma device is attached to multiple net devices, primary and other
>> upper devices such as vlan, macvlan etc",
>>
>> Can you show us an example? The rdma device is RoCE device, iWarp or ipoib
>> device?
> Rdma device is roce device.
> Add vlan, macvlan device on top of the netdevice linked to the roce device using iproute2.


  reply	other threads:[~2022-10-28  3:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-23 22:04 [PATCH 0/3] RDMA net namespace Zhu Yanjun
2022-10-23 13:04 ` Leon Romanovsky
2022-10-23 13:42   ` Yanjun Zhu
2022-10-23 16:45     ` Leon Romanovsky
2022-10-24  7:20       ` yanjun.zhu
2022-10-23 22:04 ` [PATCH 1/3] RDMA/core: Move ib device to the same net namespace with net device Zhu Yanjun
2022-10-23 22:04 ` [PATCH 2/3] RDMA/core: The legacy IB devices still work with shared/exclusive mode Zhu Yanjun
2022-10-23 22:04 ` [PATCH 3/3] RDMA/core: Get all the ib devices from net devices Zhu Yanjun
2022-10-24  1:10 ` [PATCH 0/3] RDMA net namespace Dust Li
2022-10-24  6:15   ` yanjun.zhu
2022-10-24 11:52     ` Dust Li
2022-10-24 13:12       ` Yanjun Zhu
2022-10-24 14:35         ` Dust Li
2022-10-24 16:41           ` Jason Gunthorpe
2022-10-25  2:51           ` Yanjun Zhu
2022-10-26  4:08             ` Dust Li
2022-10-26 15:01 ` Dust Li
2022-10-27  2:30   ` Dust Li
2022-10-27  2:54     ` yanjun.zhu
2022-10-27  3:01     ` Parav Pandit
2022-10-27  3:07       ` yanjun.zhu
2022-10-27  3:10         ` Parav Pandit
2022-10-27  3:17           ` yanjun.zhu
2022-10-27  3:21             ` Parav Pandit
2022-10-27  3:39               ` yanjun.zhu
2022-10-27  3:48                 ` Parav Pandit
2022-10-27  6:01                   ` yanjun.zhu
2022-10-27 14:06                     ` Parav Pandit
2022-10-28  3:21                       ` Yanjun Zhu
2022-10-28  3:31                         ` Parav Pandit
2022-10-28  3:49                           ` Yanjun Zhu [this message]
2022-10-28  3:58                             ` Parav Pandit
2022-11-11  2:38                               ` Yanjun Zhu

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=e6115b24-811e-ff61-23d3-bc3e93a4d12c@linux.dev \
    --to=yanjun.zhu@linux.dev \
    --cc=dust.li@linux.alibaba.com \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=parav@nvidia.com \
    --cc=yanjun.zhu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox