lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <77e4653d-6ad2-4b97-9952-99d506276b1a@linux.ibm.com>
Date: Tue, 11 Mar 2025 15:36:05 +0100
From: Wenjia Zhang <wenjia@...ux.ibm.com>
To: Paolo Abeni <pabeni@...hat.com>,
        Guangguan Wang <guangguan.wang@...ux.alibaba.com>, pasic@...ux.ibm.com,
        jaka@...ux.ibm.com, alibuda@...ux.alibaba.com,
        tonylu@...ux.alibaba.com, guwen@...ux.alibaba.com,
        mjambigi@...ux.ibm.com, sidraya@...ux.ibm.com
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        horms@...nel.org, linux-rdma@...r.kernel.org,
        linux-s390@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] net/smc: use the correct ndev to find pnetid
 by pnetid table



On 11.03.25 09:59, Paolo Abeni wrote:
> On 3/4/25 1:43 PM, Guangguan Wang wrote:
>> When using smc_pnet in SMC, it will only search the pnetid in the
>> base_ndev of the netdev hierarchy(both HW PNETID and User-defined
>> sw pnetid). This may not work for some scenarios when using SMC in
>> container on cloud environment.
>> In container, there have choices of different container network,
>> such as directly using host network, virtual network IPVLAN, veth,
>> etc. Different choices of container network have different netdev
>> hierarchy. Examples of netdev hierarchy show below. (eth0 and eth1
>> in host below is the netdev directly related to the physical device).
>>              _______________________________
>>             |   _________________           |
>>             |  |POD              |          |
>>             |  |                 |          |
>>             |  | eth0_________   |          |
>>             |  |____|         |__|          |
>>             |       |         |             |
>>             |       |         |             |
>>             |   eth1|base_ndev| eth0_______ |
>>             |       |         |    | RDMA  ||
>>             | host  |_________|    |_______||
>>             ---------------------------------
>>       netdev hierarchy if directly using host network
>>             ________________________________
>>             |   _________________           |
>>             |  |POD  __________  |          |
>>             |  |    |upper_ndev| |          |
>>             |  |eth0|__________| |          |
>>             |  |_______|_________|          |
>>             |          |lower netdev        |
>>             |        __|______              |
>>             |   eth1|         | eth0_______ |
>>             |       |base_ndev|    | RDMA  ||
>>             | host  |_________|    |_______||
>>             ---------------------------------
>>              netdev hierarchy if using IPVLAN
>>              _______________________________
>>             |   _____________________       |
>>             |  |POD        _________ |      |
>>             |  |          |base_ndev||      |
>>             |  |eth0(veth)|_________||      |
>>             |  |____________|________|      |
>>             |               |pairs          |
>>             |        _______|_              |
>>             |       |         | eth0_______ |
>>             |   veth|base_ndev|    | RDMA  ||
>>             |       |_________|    |_______||
>>             |        _________              |
>>             |   eth1|base_ndev|             |
>>             | host  |_________|             |
>>             ---------------------------------
>>               netdev hierarchy if using veth
>> Due to some reasons, the eth1 in host is not RDMA attached netdevice,
>> pnetid is needed to map the eth1(in host) with RDMA device so that POD
>> can do SMC-R. Because the eth1(in host) is managed by CNI plugin(such
>> as Terway, network management plugin in container environment), and in
>> cloud environment the eth(in host) can dynamically be inserted by CNI
>> when POD create and dynamically be removed by CNI when POD destroy and
>> no POD related to the eth(in host) anymore. It is hard to config the
>> pnetid to the eth1(in host). But it is easy to config the pnetid to the
>> netdevice which can be seen in POD. When do SMC-R, both the container
>> directly using host network and the container using veth network can
>> successfully match the RDMA device, because the configured pnetid netdev
>> is a base_ndev. But the container using IPVLAN can not successfully
>> match the RDMA device and 0x03030000 fallback happens, because the
>> configured pnetid netdev is not a base_ndev. Additionally, if config
>> pnetid to the eth1(in host) also can not work for matching RDMA device
>> when using veth network and doing SMC-R in POD.
>>
>> To resolve the problems list above, this patch extends to search user
>> -defined sw pnetid in the clc handshake ndev when no pnetid can be found
>> in the base_ndev, and the base_ndev take precedence over ndev for backward
>> compatibility. This patch also can unify the pnetid setup of different
>> network choices list above in container(Config user-defined sw pnetid in
>> the netdevice can be seen in POD).
>>
>> Signed-off-by: Guangguan Wang <guangguan.wang@...ux.alibaba.com>
>> ---
>>   net/smc/smc_pnet.c | 8 +++++---
>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/smc/smc_pnet.c b/net/smc/smc_pnet.c
>> index 716808f374a8..b391c2ef463f 100644
>> --- a/net/smc/smc_pnet.c
>> +++ b/net/smc/smc_pnet.c
>> @@ -1079,14 +1079,16 @@ static void smc_pnet_find_roce_by_pnetid(struct net_device *ndev,
>>   					 struct smc_init_info *ini)
>>   {
>>   	u8 ndev_pnetid[SMC_MAX_PNETID_LEN];
>> +	struct net_device *base_ndev;
>>   	struct net *net;
>>   
>> -	ndev = pnet_find_base_ndev(ndev);
>> +	base_ndev = pnet_find_base_ndev(ndev);
>>   	net = dev_net(ndev);
>> -	if (smc_pnetid_by_dev_port(ndev->dev.parent, ndev->dev_port,
>> +	if (smc_pnetid_by_dev_port(base_ndev->dev.parent, base_ndev->dev_port,
>>   				   ndev_pnetid) &&
>> +	    smc_pnet_find_ndev_pnetid_by_table(base_ndev, ndev_pnetid) &&
>>   	    smc_pnet_find_ndev_pnetid_by_table(ndev, ndev_pnetid)) {
>> -		smc_pnet_find_rdma_dev(ndev, ini);
>> +		smc_pnet_find_rdma_dev(base_ndev, ini);
>>   		return; /* pnetid could not be determined */
>>   	}
>>   	_smc_pnet_find_roce_by_pnetid(ndev_pnetid, ini, NULL, net);
> 
> I understand Wenjia opposed to this solution as it may create invalid
> topologies ?!?
> 
> https://lore.kernel.org/netdev/08cd6e15-3f8c-47a0-8490-103d59abf910@linux.ibm.com/#t
> 
> Wenjia, could you please confirm?
> 
> Thanks,
> 
> Paolo
> 

Hi Paolo,

Thanks for asking! I really appreciate it.

I was initially opposed, but after discussing with Halil, I agreed that 
my concerns might be not necessary. Halil and I reached an agreement 
that he responded to the emails (v1) to ask for the version as he 
already did, and we will double-check version 2 to ensure it works 
correctly.

In any case, I still need to review it carefully and will provide my 
answer as soon as possible.

Thanks,
Wenjia

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ