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.
next prev parent 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