[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YgOngV93e8IYr8bv@TonyMac-Alibaba>
Date: Wed, 9 Feb 2022 19:37:37 +0800
From: Tony Lu <tonylu@...ux.alibaba.com>
To: "D. Wythe" <alibuda@...ux.alibaba.com>
Cc: kgraul@...ux.ibm.com, kuba@...nel.org, davem@...emloft.net,
netdev@...r.kernel.org, linux-s390@...r.kernel.org,
linux-rdma@...r.kernel.org
Subject: Re: [PATCH net-next v5 5/5] net/smc: Add global configure for auto
fallback by netlink
On Wed, Feb 09, 2022 at 05:53:18PM +0800, D. Wythe wrote:
>
>
> 在 2022/2/9 下午5:16, Tony Lu 写道:
> > On Tue, Feb 08, 2022 at 08:53:13PM +0800, D. Wythe wrote:
> > > From: "D. Wythe" <alibuda@...ux.alibaba.com>
> > >
> > > @@ -248,6 +248,8 @@ int smc_nl_get_sys_info(struct sk_buff *skb, struct netlink_callback *cb)
> > > goto errattr;
> > > if (nla_put_u8(skb, SMC_NLA_SYS_IS_SMCR_V2, true))
> > > goto errattr;
> > > + if (nla_put_u8(skb, SMC_NLA_SYS_AUTO_FALLBACK, smc_auto_fallback))
> >
> > READ_ONCE(smc_auto_fallback) ?
>
>
> No READ_ONCE() will cause ?
Make sure that we read the current value.
>
> > > + goto errattr;
> > > smc_clc_get_hostname(&host);
> > > if (host) {
> > > memcpy(hostname, host, SMC_MAX_HOSTNAME_LEN);
> > > diff --git a/net/smc/smc_netlink.c b/net/smc/smc_netlink.c
> > > index f13ab06..a7de517 100644
> > > --- a/net/smc/smc_netlink.c
> > > +++ b/net/smc/smc_netlink.c
> > > @@ -111,6 +111,16 @@
> > > .flags = GENL_ADMIN_PERM,
> > > .doit = smc_nl_disable_seid,
> > > },
> > > + {
> > > + .cmd = SMC_NETLINK_ENABLE_AUTO_FALLBACK,
> > > + .flags = GENL_ADMIN_PERM,
> > > + .doit = smc_enable_auto_fallback,
> > > + },
> > > + {
> > > + .cmd = SMC_NETLINK_DISABLE_AUTO_FALLBACK,
> > > + .flags = GENL_ADMIN_PERM,
> > > + .doit = smc_disable_auto_fallback,
> > > + },
> > > };
> >
> > Consider adding the separated cmd to query the status of this config,
> > just as SEID does?
> >
> > It is common to check this value after user-space setted. Combined with
> > sys_info maybe a little heavy in this scene.
>
>
> Add a independent dumpit is quite okay, but is there have really scenarios
> that access this value frequently? With more and more such switches in the
> future, is is necessary for us to repeat on each switch ? I do have a plan
> to put them unified within a NLA attributes, but I don't have much time yet.
Yes, I think spreading them make code clean, and we can keep ABI
compatibility if we have more than one interface. If we want to change
one knob, we can change itself functions and data structures. Also, it
makes userspace tools easy to maintainer. TCP's procfs, like /proc/net/netstat,
is a summary knob, but not easy to parse and extend. Given that we
choose modern netlink, we can avoid it from the beginning.
Thanks,
Tony Lu
Powered by blists - more mailing lists