From: Hangbin Liu <liuhangbin@gmail.com>
To: Nikolay Aleksandrov <razor@blackwall.org>,
Jay Vosburgh <jay.vosburgh@canonical.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Andy Gospodarek <andy@greyhouse.net>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Ido Schimmel <idosch@nvidia.com>,
Jiri Pirko <jiri@resnulli.us>, Amit Cohen <amcohen@nvidia.com>
Subject: Re: [PATCHv3 net-next] bonding: 3ad: send ifinfo notify when mux state changed
Date: Thu, 27 Jun 2024 21:17:17 +0800 [thread overview]
Message-ID: <Zn1mXRRINDQDrIKw@Laptop-X1> (raw)
In-Reply-To: <89249184-41ac-42f6-b5af-4a46f9b28247@blackwall.org>
On Thu, Jun 27, 2024 at 01:33:10PM +0300, Nikolay Aleksandrov wrote:
> > Yes, but at least the admin could get the latest state. With the following
> > code the admin may not get the latest update if lock rtnl failed.
> >
> > if (should_notify_rtnl && rtnl_trylock()) {
> > bond_slave_lacp_notify(bond);
> > rtnl_unlock();
> > }
> >
> Well, you mentioned administrators want to see the state changes, please
> better clarify the exact end goal. Note that technically may even not be
> the last state as the state change itself happens in parallel (different
> locks) and any update could be delayed depending on rtnl availability
> and workqueue re-scheduling. But sure, they will get some update at some point. :)
Ah.. Yes, that's a sad fact :(
>
> It all depends on what are the requirements.
>
> An uglier but lockless alternative would be to poll the slave's sysfs oper state,
> that doesn't require any locks and would be up-to-date.
Hmm, that's a workaround, but the admin need to poll the state frequently as
they don't know when the state will change.
Hi Jay, are you OK to add this sysfs in bonding?
Thanks
Hangbin
next prev parent reply other threads:[~2024-06-27 13:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 7:51 [PATCHv3 net-next] bonding: 3ad: send ifinfo notify when mux state changed Hangbin Liu
2024-06-26 8:22 ` Nikolay Aleksandrov
2024-06-26 15:30 ` Jay Vosburgh
2024-06-26 21:53 ` Jakub Kicinski
2024-06-27 0:06 ` Jay Vosburgh
2024-06-27 8:26 ` Hangbin Liu
2024-06-27 8:29 ` Nikolay Aleksandrov
2024-06-27 10:05 ` Hangbin Liu
2024-06-27 10:33 ` Nikolay Aleksandrov
2024-06-27 13:17 ` Hangbin Liu [this message]
2024-06-27 14:12 ` Nikolay Aleksandrov
2024-06-27 14:24 ` Jay Vosburgh
2024-06-28 3:10 ` Hangbin Liu
2024-06-28 7:04 ` Nikolay Aleksandrov
2024-06-28 7:22 ` Nikolay Aleksandrov
2024-06-28 9:55 ` Hangbin Liu
2024-06-28 23:36 ` Jay Vosburgh
2024-07-02 8:00 ` Hangbin Liu
2024-07-11 3:12 ` Hangbin Liu
2024-07-19 6:45 ` Hangbin Liu
2024-07-29 7:43 ` Hangbin Liu
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=Zn1mXRRINDQDrIKw@Laptop-X1 \
--to=liuhangbin@gmail.com \
--cc=amcohen@nvidia.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=jay.vosburgh@canonical.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
/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).