From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Mateusz Palczewski <mateusz.palczewski@intel.com>
Cc: andy@greyhouse.net, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, dbanerje@akamai.com,
netdev@vger.kernel.org,
Sebastian Basierski <sebastianx.basierski@intel.com>
Subject: Re: [PATCH iwl-net v1 2/2] drivers/net/bonding: Added some delay while checking for VFs link
Date: Tue, 16 May 2023 08:15:42 -0700 [thread overview]
Message-ID: <32200.1684250142@famine> (raw)
In-Reply-To: <20230516134447.193511-3-mateusz.palczewski@intel.com>
Mateusz Palczewski <mateusz.palczewski@intel.com> wrote:
>From: Sebastian Basierski <sebastianx.basierski@intel.com>
>
>Right now bonding driver checks if link is ready once.
>VF interface takes a little more time to get ready than PF,
>so driver needs to wait for it to be ready.
>1000ms delay was set, if VF link will not be set within given amount
>of time, for sure problems should be investigated elsewhere.
Why is the "updelay" mechanism that's already available
insufficient for this purpose?
Even without updelay, I'd expect the behavior to simply be that
the carrier state flaps once or twice (because the VF is delayed in
asserting carrier up). This is reflecting reality; I'm unsure why we
would want to hack in an extra delay to cover that up.
Regardless of whether updelay handles this case or not, adding a
1 second busy wait loop as this patch does is not a reasonable
implementation. This would cause a 1 second stall in the link state
check for every bond interface that is carrier down.
-J
>Fixes: b3c898e20b18 ("Revert "bonding: allow carrier and link status to determine link state"")
>Signed-off-by: Sebastian Basierski <sebastianx.basierski@intel.com>
>Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
>---
> drivers/net/bonding/bond_main.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 710548dbd0c1..6d49fb25969e 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -736,6 +736,8 @@ const char *bond_slave_link_status(s8 link)
> * It'd be nice if there was a good way to tell if a driver supports
> * netif_carrier, but there really isn't.
> */
>+#define BOND_CARRIER_CHECK_TIMEOUT 1000
>+
> static int bond_check_dev_link(struct bonding *bond,
> struct net_device *slave_dev, int reporting)
> {
>@@ -743,12 +745,22 @@ static int bond_check_dev_link(struct bonding *bond,
> int (*ioctl)(struct net_device *, struct ifreq *, int);
> struct ifreq ifr;
> struct mii_ioctl_data *mii;
>+ int delay;
>
> if (!reporting && !netif_running(slave_dev))
> return 0;
>
>+ for (delay = 0; delay < BOND_CARRIER_CHECK_TIMEOUT; delay++) {
>+ mdelay(1);
>+
>+ if (bond->params.use_carrier &&
>+ netif_carrier_ok(slave_dev)) {
>+ return BMSR_LSTATUS;
>+ }
>+ }
>+
> if (bond->params.use_carrier)
>- return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
>+ return 0;
>
> /* Try to get link status using Ethtool first. */
> if (slave_dev->ethtool_ops->get_link)
>--
>2.31.1
>
>
---
-Jay Vosburgh, jay.vosburgh@canonical.com
prev parent reply other threads:[~2023-05-16 15:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 13:44 [PATCH iwl-net v1 0/2] Fix for bond 802.3ad mode with VFs Mateusz Palczewski
2023-05-16 13:44 ` [PATCH iwl-net v1 1/2] drivers/net/bonding/bond_3ad: Use updated MAC address for lacpdu packets Mateusz Palczewski
2023-05-16 15:02 ` Jay Vosburgh
2023-05-16 13:44 ` [PATCH iwl-net v1 2/2] drivers/net/bonding: Added some delay while checking for VFs link Mateusz Palczewski
2023-05-16 15:15 ` Jay Vosburgh [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=32200.1684250142@famine \
--to=jay.vosburgh@canonical.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=dbanerje@akamai.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=mateusz.palczewski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sebastianx.basierski@intel.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).