From: Hangbin Liu <liuhangbin@gmail.com>
To: Jay Vosburgh <jay.vosburgh@canonical.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>,
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: Fri, 28 Jun 2024 11:10:27 +0800 [thread overview]
Message-ID: <Zn4po-wJoFat3CUd@Laptop-X1> (raw)
In-Reply-To: <1467748.1719498250@famine>
On Thu, Jun 27, 2024 at 07:24:10AM -0700, Jay Vosburgh wrote:
> Hangbin Liu <liuhangbin@gmail.com> wrote:
> >Ah.. Yes, that's a sad fact :(
>
> There are basically two paths that will change the LACP state
> that's passed up via netlink (the aggregator ID, and actor and partner
> oper port states): bond_3ad_state_machine_handler(), or incoming
> LACPDUs, which call into ad_rx_machine(). Administrative changes to the
Ah, thanks, I didn't notice this. I will also enable lacp notify
in ad_rx_machine().
> bond will do it too, like adding or removing interfaces, but those
> originate in user space and aren't happening asynchronously.
>
> If you want (almost) absolute reliability in communicating every
> state change for the state machine and LACPDU processing, I think you'd
> have to (a) create an object with the changed state, (b) queue it
> somewhere, then (c) call a workqueue event to process that queue out of
> line.
Hmm... This looks too complex. If we store all the states. A frequent flashing
may consume the memory. If we made a limit for the queue, we may still loosing
some state changes.
I'm not sure which way is better.
>
> >> 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?
>
> I think what Nik is proposing is for your userspace to poll the
> /sys/class/net/${DEV}/operstate.
OK. There are 2 scenarios I got.
1) the local user want to get the local/partner state and make sure not
send pkts before they are in DISTRIBUTING state to avoid pkts drop, Or vice
versa. Only checking link operstate or up/down status is not enough.
2) the admin want to get the switch/partner status via LACP status incase
the switch is crashed.
Do you have any suggestion for the implementation?
Thanks
Hangbin
next prev parent reply other threads:[~2024-06-28 3:10 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
2024-06-27 14:12 ` Nikolay Aleksandrov
2024-06-27 14:24 ` Jay Vosburgh
2024-06-28 3:10 ` Hangbin Liu [this message]
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=Zn4po-wJoFat3CUd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.