netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wenjia Zhang <wenjia@linux.ibm.com>
To: Guangguan Wang <guangguan.wang@linux.alibaba.com>,
	Halil Pasic <pasic@linux.ibm.com>
Cc: jaka@linux.ibm.com, alibuda@linux.alibaba.com,
	tonylu@linux.alibaba.com, guwen@linux.alibaba.com,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, linux-rdma@vger.kernel.org,
	linux-s390@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Dust Li <dust.li@linux.alibaba.com>
Subject: Re: [PATCH net-next v2 2/2] net/smc: support ipv4 mapped ipv6 addr client for smc-r v2
Date: Fri, 6 Dec 2024 20:49:23 +0100	[thread overview]
Message-ID: <3710a042-cabe-4b6d-9caa-fd4d864b2fdc@linux.ibm.com> (raw)
In-Reply-To: <7de81edd-86f2-4cfd-95db-e273c3436eb6@linux.ibm.com>



On 06.12.24 11:51, Wenjia Zhang wrote:
> 
> 
> On 06.12.24 07:06, Guangguan Wang wrote:
>>
>>
>> On 2024/12/5 20:58, Halil Pasic wrote:
>>> On Thu, 5 Dec 2024 11:16:27 +0100
>>> Wenjia Zhang <wenjia@linux.ibm.com> wrote:
>>>
>>>>> --- a/net/smc/af_smc.c
>>>>> +++ b/net/smc/af_smc.c
>>>>> @@ -1116,7 +1116,12 @@ static int smc_find_proposal_devices(struct
>>>>> smc_sock *smc, ini->check_smcrv2 = true;
>>>>>        ini->smcrv2.saddr = smc->clcsock->sk->sk_rcv_saddr;
>>>>>        if (!(ini->smcr_version & SMC_V2) ||
>>>>> +#if IS_ENABLED(CONFIG_IPV6)
>>>>> +        (smc->clcsock->sk->sk_family != AF_INET &&
>>>>> +
>>>>> !ipv6_addr_v4mapped(&smc->clcsock->sk->sk_v6_rcv_saddr)) ||
>>>> I think here you want to say !(smc->clcsock->sk->sk_family == AF_INET
>>>> && ipv6_addr_v4mapped(&smc->clcsock->sk->sk_v6_rcv_saddr)), right? If
>>>> it is, the negativ form of the logical operation (a&&b) is (!a)||(!b),
>>>> i.e. here should be:
>>>> (smc->clcsock->sk->sk_family != AF_INET)||
>>>> (!ipv6_addr_v4mapped(&smc->clcsock->sk->sk_v6_rcv_saddr))
>>>
>>> Wenjia, I think you happen to confuse something here. The condition
>>> of this if statement is supposed to evaluate as true iff we don't want
>>> to propose SMCRv2 because the situation is such that SMCRv2 is not
>>> supported.
>>>
>>> We have a bunch of conditions we need to meet for SMCRv2 so
>>> logically we have (A && B && C && D). Now since the if is
>>> about when SMCRv2 is not supported we have a super structure
>>> that looks like !A || !B || !C || !D. With this patch, if
>>> CONFIG_IPV6 is not enabled, the sub-condition remains the same:
>>> if smc->clcsock->sk->sk_family is something else that AF_INET
>>> the we do not do SMCRv2!
>>>
>>> But when we do have CONFIG_IPV6 then we want to do SMCRv2 for
>>> AF_INET6 sockets too if the addresses used are actually
>>> v4 mapped addresses.
>>>
>>> Now this is where the cognitive dissonance starts on my end. I
>>> think the author assumes sk_family == AF_INET || sk_family == AF_INET6
>>> is a tautology in this context. That may be a reasonable thing to
>>> assume. Under that assumption
>>> sk_family != AF_INET &&    !ipv6_addr_v4mapped(addr) (shortened for
>>> convenience)
>>> becomes equivalent to
>>> sk_family == AF_INET6 && !ipv6_addr_v4mapped(addr)
>>> which means in words if the socket is an IPv6 sockeet and the addr is 
>>> not
>>> a v4 mapped v6 address then we *can not* do SMCRv2. And the condition
>>> when we can is sk_family != AF_INET6 || ipv6_addr_v4mapped(addr) which
>>> is equivalen to sk_family == AF_INET || ipv6_addr_v4mapped(addr) under
>>> the aforementioned assumption.
>>
>> Hi, Halil
>>
>> Thank you for such a detailed derivation.
>>
>> Yes, here assume that sk_family == AF_INET || sk_family == AF_INET6. 
>> Indeed,
>> many codes in SMC have already made this assumption, for example,
>> static int __smc_create(struct net *net, struct socket *sock, int 
>> protocol,
>>             int kern, struct socket *clcsock)
>> {
>>     int family = (protocol == SMCPROTO_SMC6) ? PF_INET6 : PF_INET;
>>     ...
>> }
>> And I also believe it is reasonable.
>>
>> Before this patch, for SMCR client, only an IPV4 socket can do SMCRv2. 
>> This patch
>> introduce an IPV6 socket with v4 mapped v6 address for SMCRv2. It is 
>> equivalen
>> to sk_family == AF_INET || ipv6_addr_v4mapped(addr) as you described.
>>
>>>
>>> But if we assume sk_family == AF_INET || sk_family == AF_INET6 then
>>> the #else does not make any sense, because I guess with IPv6 not
>>> available AF_INET6 is not available ant thus the else is always
>>> guaranteed to evaluate to false under the assumption made.
>>>
>> You are right. The #else here does not make any sense. It's my mistake.
>>
>> The condition is easier to understand and read should be like this:
>>       if (!(ini->smcr_version & SMC_V2) ||
>> +#if IS_ENABLED(CONFIG_IPV6)
>> +        (smc->clcsock->sk->sk_family == AF_INET6 &&
>> +         !ipv6_addr_v4mapped(&smc->clcsock->sk->sk_v6_rcv_saddr)) ||
>> +#endif
>>           !smc_clc_ueid_count() ||
>>           smc_find_rdma_device(smc, ini))
>>           ini->smcr_version &= ~SMC_V2;
>>
> 
> sorry, I still don't agree on this version. You removed the condition
> "
> smc->clcsock->sk->sk_family != AF_INET ||
> "
> completely. What about the socket with neither AF_INET nor AF_INET6 family?
> 
> Thanks,
> Wenjia
> 
I think the main problem in the original version was that
(sk_family != AF_INET) is not equivalent to (sk_family == AF_INET6).
Since you already in the new version above used sk_family == AF_INET6,
the else condition could stay as it is. My suggestion:

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 8e3093938cd2..5f205a41fc48 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1116,7 +1116,12 @@ static int smc_find_proposal_devices(struct 
smc_sock *smc,
         ini->check_smcrv2 = true;
         ini->smcrv2.saddr = smc->clcsock->sk->sk_rcv_saddr;
         if (!(ini->smcr_version & SMC_V2) ||
+#if IS_ENABLED(CONFIG_IPV6)
+           (smc->clcsock->sk->sk_family == AF_INET6 &&
+            !ipv6_addr_v4mapped(&smc->clcsock->sk->sk_v6_rcv_saddr)) ||
+#else
             smc->clcsock->sk->sk_family != AF_INET ||
+#endif
             !smc_clc_ueid_count() ||
             smc_find_rdma_device(smc, ini))
                 ini->smcr_version &= ~SMC_V2;

Thanks,
Wenjia

  reply	other threads:[~2024-12-06 19:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-02 12:52 [PATCH net-next v2 0/2] net/smc: Two features for smc-r Guangguan Wang
2024-12-02 12:52 ` [PATCH net-next v2 1/2] net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1 Guangguan Wang
2024-12-06 19:12   ` Wenjia Zhang
2024-12-02 12:52 ` [PATCH net-next v2 2/2] net/smc: support ipv4 mapped ipv6 addr client for smc-r v2 Guangguan Wang
2024-12-05 10:16   ` Wenjia Zhang
2024-12-05 12:02     ` Guangguan Wang
2024-12-05 12:58     ` Halil Pasic
2024-12-06  6:06       ` Guangguan Wang
2024-12-06 10:51         ` Wenjia Zhang
2024-12-06 19:49           ` Wenjia Zhang [this message]
2024-12-09  6:04             ` Guangguan Wang
2024-12-09  8:49               ` Wenjia Zhang
2024-12-09  9:46                 ` Halil Pasic
2024-12-09 12:36                   ` Guangguan Wang
2024-12-09 20:44                     ` Halil Pasic
2024-12-10  7:07                       ` Guangguan Wang
2024-12-10  9:59                         ` Halil Pasic
2024-12-05  2:39 ` [PATCH net-next v2 0/2] net/smc: Two features for smc-r Jakub Kicinski
2024-12-05  7:27   ` Wenjia Zhang

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=3710a042-cabe-4b6d-9caa-fd4d864b2fdc@linux.ibm.com \
    --to=wenjia@linux.ibm.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=dust.li@linux.alibaba.com \
    --cc=edumazet@google.com \
    --cc=guangguan.wang@linux.alibaba.com \
    --cc=guwen@linux.alibaba.com \
    --cc=horms@kernel.org \
    --cc=jaka@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=tonylu@linux.alibaba.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;
as well as URLs for NNTP newsgroup(s).