Received-SPF: pass (google.com: domain of linux-kernel+bounces-181864-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <c3c13531-f8be-4159-b8df-b316adb2d3fc@linux.ibm.com>
Date: Fri, 17 May 2024 09:41:09 +0200
User-Agent: Mozilla Thunderbird
From: Wenjia Zhang <wenjia@linux.ibm.com>
Subject: Re: some questions about restrictions in SMC-R v2's implementation
To: Guangguan Wang <guangguan.wang@linux.alibaba.com>, jaka@linux.ibm.com,
        kgraul@linux.ibm.com
Cc: linux-s390@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <6d6e870a-3fbf-4802-9818-32ff46489448@linux.alibaba.com>
Content-Language: en-US
In-Reply-To: <6d6e870a-3fbf-4802-9818-32ff46489448@linux.alibaba.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0


On 07.05.24 07:54, Guangdong Wang wrote:
> Hi, Wenjia and Jan,
> 
> When testing SMC-R v2, I found some scenarios where SMC-R v2 should be worked, but due to some restrictions in SMC-R v2's implementation,
> fallback happened. I want to know why these restrictions exist and what would happen if these restrictions were removed.
> 

Hi Guangguan and Wen,

please see my answer below.
> The first is in the function smc_ib_determine_gid_rcu, where restricts the subnet matching between smcrv2->saddr and the RDMA related netdev.
> codes here:
> static int smc_ib_determine_gid_rcu(...)
> {
>      ...
>          in_dev_for_each_ifa_rcu(ifa, in_dev) {
>              if (!inet_ifa_match(smcrv2->saddr, ifa))
>                  continue;
>              subnet_match = true;
>              break;
>          }
>          if (!subnet_match)
>              goto out;
>      ...
> out:
>      return -ENODEV;
> }
> In my testing environment, either server or client, exists two netdevs, eth0 in netnamespace1 and eth0 in netnamespace2. For the sake of clarity
> in the following text, we will refer to eth0 in netnamespace1 as eth1, and eth0 in netnamespace2 as eth2. The eth1's ip is 192.168.0.3/32 and the
> eth2's ip is 192.168.0.4/24. The netmask of eth1 must be 32 due to some reasons. The eth1 is a RDMA related netdev, which means the adaptor of eth1
> has RDMA function. The eth2 has been associated to the eth1's RDMA device using smc_pnet. When testing connection in netnamespace2(using eth2 for
> SMC-R connection), we got fallback connection, rsn is 0x03010000, due to the above subnet matching restriction. But in this scenario, I think
> SMC-R should work.
> In my another testing environment, either server or client, exists two netdevs, eth0 in netnamespace1 and eth1 in netnamespace1. The eth0's ip is
> 192.168.0.3/24 and the eth1's ip is 192.168.1.4/24. The eth0 is a RDMA related netdev, which means the adaptor of eth0 has RDMA function. The eth1 has
> been associated to the eth0's RDMA device using smc_pnet. When testing SMC-R connection through eth1, we got fallback connection, rsn is 0x03010000,
> due to the above subnet matching restriction. In my environment, eth0 and eth1 have the same network connectivity even though they have different
> subnet. I think SMC-R should work in this scenario.
> 
The purpose of the restriction is to simplify the IP routing topology 
allowing IP routing to use the destination host's subnet route. Because 
each host must also have a valid IP route to the peer’s RoCE IP address 
to create RC QP. If the IP route used is the same IP Route as the 
associated TCP/IP connection, the reuse of the IP routing topology could 
be achieved. I think it is what the following sentence means in the doc 
https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Shared%20Memory%20Communications%20Version%202_2.pdf

"
For HA, multiple RoCE adapters should be provisioned along with multiple 
equal cost IP routes to the peer host (i.e., reusing the TCP/IP routing 
topology).
"
And the "Figure 19. SMC-Rv2 with RoCEv2 Connectivity" in the doc also 
mentions the restriction.

The SMCRv2 on linux is indeed implemented with this purpose. Please see 
the function smc_ib_modify_qp_rtr(). During the first contact 
processing, the Mac address of the next hop IP address for the IP route 
is resolved by performing e.g. ARP and used to create the RoCEv2 RC QP. 
If the route is not usable for the RoCE IP address to reach the peer's 
RoCE IP address i.e. without this restriction, the UDP/IP packets would 
not be transported in a right way.

BTW, the fallback would still happen without the restriction. Because at 
the end of the CLC handshake(TCP/IP traffic), the first link will be 
created by sending and receiving LLC confirm message (SMCRv2 traffic). 
If one peer can just send but not receive the LLC confirm message, he 
will send CLC decline message with the reason "Time Out".

Now let's have a look at your examples above. Both of your RDMA related 
device have another IP route as the TCP/IP connection, so that the reuse 
of the IP routing topology is not possible.

Any thought still?

> The other is in the function smc_connect_rdma_v2_prepare, where restricts the symmetric configuration of routing between client and server. codes here:
> static int smc_connect_rdma_v2_prepare(...)
> {
>      ...
>      if (fce->v2_direct) {
>          memcpy(ini->smcrv2.nexthop_mac, &aclc->r0.lcl.mac, ETH_ALEN);
>          ini->smcrv2.uses_gateway = false;
>      } else {
>          if (smc_ib_find_route(net, smc->clcsock->sk->sk_rcv_saddr,
>                smc_ib_gid_to_ipv4(aclc->r0.lcl.gid),
>                ini->smcrv2.nexthop_mac,
>                &ini->smcrv2.uses_gateway))
>              return SMC_CLC_DECL_NOROUTE;
>          if (!ini->smcrv2.uses_gateway) {
>              /* mismatch: peer claims indirect, but its direct */
>              return SMC_CLC_DECL_NOINDIRECT;
>          }
>      }
>      ...
> }
> In my testing environment, server's ip is 192.168.0.3/24, client's ip 192.168.0.4/24, regarding how many netdev in server or client. Server has special
> route setting due to some other reasons, which results in indirect route from 192.168.0.3/24 to 192.168.0.4/24. Thus, when CLC handshake, client will
> get fce->v2_direct==false, but client has no special routing setting and will find direct route from 192.168.0.4/24 to 192.168.0.3/24. Due to the above
> symmetric configuration of routing restriction, we got fallback connection, rsn is 0x030f0000. But I think SMC-R should work in this scenario.
> And more, why check the symmetric configuration of routing only when server is indirect route?
> 
That is to check if the IP routing topology is the same on both sides. 
Then I'd like to ask why you use asymmetric routing for your connection? 
 From the perspective of Networking set up, does it make any sense that 
the peers communicate with each other with different IP routing topology?
> Waiting for your reply.
> 
> Thanks,
> Guangguan Wang
>