From: Simon Horman <horms@kernel.org>
To: "D. Wythe" <alibuda@linux.alibaba.com>
Cc: kgraul@linux.ibm.com, wenjia@linux.ibm.com, jaka@linux.ibm.com,
wintera@linux.ibm.com, guwen@linux.alibaba.com, kuba@kernel.org,
davem@davemloft.net, netdev@vger.kernel.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org,
tonylu@linux.alibaba.com, pabeni@redhat.com, edumazet@google.com
Subject: Re: [PATCH net-next v4 3/3] net/smc: Introduce IPPROTO_SMC
Date: Mon, 3 Jun 2024 08:47:32 +0100 [thread overview]
Message-ID: <20240603074732.GW491852@kernel.org> (raw)
In-Reply-To: <83a6596b-d9c4-4f2f-9eae-fd35cae561dc@linux.alibaba.com>
On Mon, Jun 03, 2024 at 10:57:55AM +0800, D. Wythe wrote:
>
>
> On 6/1/24 9:06 PM, Simon Horman wrote:
> > On Wed, May 29, 2024 at 11:59:07AM +0800, D. Wythe wrote:
> > > From: "D. Wythe" <alibuda@linux.alibaba.com>
> > >
> > > This patch allows to create smc socket via AF_INET,
> > > similar to the following code,
> > >
> > > /* create v4 smc sock */
> > > v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_SMC);
> > >
> > > /* create v6 smc sock */
> > > v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_SMC);
> > >
> > > There are several reasons why we believe it is appropriate here:
> > >
> > > 1. For smc sockets, it actually use IPv4 (AF-INET) or IPv6 (AF-INET6)
> > > address. There is no AF_SMC address at all.
> > >
> > > 2. Create smc socket in the AF_INET(6) path, which allows us to reuse
> > > the infrastructure of AF_INET(6) path, such as common ebpf hooks.
> > > Otherwise, smc have to implement it again in AF_SMC path.
> > >
> > > Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
> > ...
> >
> > > diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> > ...
> >
> > > @@ -3594,9 +3595,31 @@ static int __init smc_init(void)
> > > goto out_lo;
> > > }
> > > + rc = proto_register(&smc_inet_prot, 1);
> > > + if (rc) {
> > > + pr_err("%s: proto_register smc_inet_prot fails with %d\n", __func__, rc);
> > Hi,
> >
> > FWIIW, my feeling is that if a log message includes __func__ then it should
> > be a debug level message, and even then I'm dubious about the value of
> > __func__: we do have many tools including dynamic tracing or pinpointing
> > problems.
> >
> > So I would suggest rephrasing this message and dropping __func__.
> > Or maybe removing it entirely.
> > Or if not, lowering the priority of this message to debug.
> >
> > If for some reason __func__ remains, please do consider wrapping
> > the line to 80c columns or less, which can be trivially done here
> > (please don't split the format string in any case).
> >
> > Flagged by checkpatch.pl --max-line-length=80
>
>
> Hi Simon,
>
> Thank you very much for your feedback.
>
> Allow me to briefly explain the reasons for using pr_err and __func__ here.
>
> Regarding pr_err, the failure here leads to the failure of the module
> loading, which is definitely an error-level message rather than a
> debug-level one.
>
> As for __func__, I must admit that the purpose here is simply to align with
> the format of other error messages in smc_init(). In fact, I also feel that
> the presence of
> __func__ doesn't hold significant value because this error will only occur
> within this function. It's meaningless information for both users and kernel
> developers.
> Perhaps a more suitable format would be “smc: xxx: %d”.
>
> However, if changes are needed, I think they should be made across the board
> in order to maintain a consistent style. Maybe this can be addressed by
> submitting a new patch after this patch. @Wenjia, what do you think?
>
> Therefore, for now, I would like to wrap this line to not exceed 80
> characters, to ensure it can pass the checkpatch.pl.
> What do you think?
Thanks, I agree with your reasoning.
And I think this is a good approach for this patch.
>
> Best wishes,
> D. Wythe
>
> >
> > > + goto out_ulp;
> > > + }
> > > + inet_register_protosw(&smc_inet_protosw);
> > > +#if IS_ENABLED(CONFIG_IPV6)
> > > + rc = proto_register(&smc_inet6_prot, 1);
> > > + if (rc) {
> > > + pr_err("%s: proto_register smc_inet6_prot fails with %d\n", __func__, rc);
> > Here too.
> >
> > > + goto out_inet_prot;
> > > + }
> > > + inet6_register_protosw(&smc_inet6_protosw);
> > > +#endif
> > ...
>
prev parent reply other threads:[~2024-06-03 7:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 3:59 [PATCH net-next v4 0/3] Introduce IPPROTO_SMC D. Wythe
2024-05-29 3:59 ` [PATCH net-next v4 1/3] net/smc: refactoring initialization of smc sock D. Wythe
2024-05-29 6:14 ` Tony Lu
2024-05-29 3:59 ` [PATCH net-next v4 2/3] net/smc: expose smc proto operations D. Wythe
2024-05-29 17:57 ` Zhu Yanjun
2024-05-30 2:33 ` D. Wythe
2024-05-29 3:59 ` [PATCH net-next v4 3/3] net/smc: Introduce IPPROTO_SMC D. Wythe
2024-05-29 11:12 ` Dust Li
2024-05-30 3:11 ` D. Wythe
2024-05-29 11:58 ` Wenjia Zhang
2024-05-30 2:51 ` D. Wythe
2024-05-29 19:55 ` Zhu Yanjun
2024-05-30 2:35 ` D. Wythe
2024-06-01 13:06 ` Simon Horman
2024-06-03 2:57 ` D. Wythe
2024-06-03 7:47 ` Simon Horman [this message]
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=20240603074732.GW491852@kernel.org \
--to=horms@kernel.org \
--cc=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=guwen@linux.alibaba.com \
--cc=jaka@linux.ibm.com \
--cc=kgraul@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tonylu@linux.alibaba.com \
--cc=wenjia@linux.ibm.com \
--cc=wintera@linux.ibm.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).