From: Dan Williams <dcbw@redhat.com>
To: james@nurealm.net, Andreas Born <futur.andy@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>,
Arend van Spriel <arend.vanspriel@broadcom.com>,
Mahesh Bandewar <maheshb@google.com>,
Andy Gospodarek <andy@greyhouse.net>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
Ben Greear <greearb@candelatech.com>
Subject: Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers
Date: Wed, 16 Aug 2017 16:22:41 -0500 [thread overview]
Message-ID: <1502918561.30484.1.camel@redhat.com> (raw)
In-Reply-To: <2b6fd91a-f7cd-c2bf-6394-060d9b1f5d23@nurealm.net>
On Wed, 2017-08-16 at 14:44 -0600, James Feeney wrote:
> On 08/13/2017 11:42 AM, Andreas Born wrote:
> > On a side note I would recommend some of my own reading to you
> > about
> > patch submission in general [1] and on netdev specifically [2].
>
> Mmm - [2] and [3], I suspect. Thanks Andreas. I'll be studying
> those. Yeah,
> I'm still learning what is needed and what works. Sometimes, just a
> note to the
> author is more than enough to resolve a problem. Sometimes,
> discussion is
> needed. And other times... well, certain people are infamous... but
> no problem
> here, thankfully.
>
> > And, just wondering, who's going to eventually close that
> > bugreport?
> > https://bugzilla.kernel.org/show_bug.cgi?id=196547
>
> I can close it when the patches actually land in the kernel. I'm
> glad to see
> that there was an "Ack" from Mahesh.
>
> On the topic of wireless support for kernel ethtool reporting, I'm
> wondering, is
> there is any consensus about that?
>
> And, for instance, is there any *other* way for the bonding module to
> make
> "better link" decisions for wireless links? As "wireless" becomes
> more capable,
> possibly more diverse, and probably more essential for computing,
> this is likely
> to become a bigger issue.
>
> Ben Greear mentioned that he had added some support to the ath10k
> driver. Dan
> Williams mentioned the possibility of updating the mac80211 stack for
> support.
> And Arend van Spriel suggested that the issue might best be left for
> the next
> Netconf.
>
> Immediate problem solved, but maybe a larger issue still needs to be
> addressed?
Again, it's technically possible to add the link settings support to
wireless drivers. But the issue is around what bonding would do with
that information in its various modes.
My biggest suggestion is that perhaps bonding should grow hysteresis
for link speeds. Since WiFi can change speed every packet, you probably
don't want the bond characteristics changing every couple seconds just
in case your WiFi link is jumping around. Ethernet won't bounce around
that much, so the hysteresis would have no effect there. Or, if people
are concerned about response time to speed changes on ethernet (where
you probably do want an instant switch-over) some new flag to indicate
that certain devices don't have stable speeds over time.
Dan
next prev parent reply other threads:[~2017-08-16 21:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 5:39 Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers Kalle Valo
2017-08-10 12:43 ` Arend van Spriel
2017-08-10 17:52 ` Andreas Born
2017-08-11 13:14 ` Kalle Valo
2017-08-12 7:35 ` Kalle Valo
2017-08-12 19:30 ` James Feeney
2017-08-13 17:42 ` Andreas Born
2017-08-16 20:44 ` James Feeney
2017-08-16 21:01 ` David Miller
2017-08-16 21:22 ` Dan Williams [this message]
2017-08-16 21:31 ` David Miller
2017-08-17 2:11 ` Dan Williams
2017-08-17 2:36 ` Ben Greear
2017-08-17 3:18 ` Dan Williams
2017-08-17 3:32 ` Ben Greear
2017-08-17 2:42 ` David Miller
2017-08-17 5:33 ` Jay Vosburgh
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=1502918561.30484.1.camel@redhat.com \
--to=dcbw@redhat.com \
--cc=andy@greyhouse.net \
--cc=arend.vanspriel@broadcom.com \
--cc=davem@davemloft.net \
--cc=futur.andy@googlemail.com \
--cc=greearb@candelatech.com \
--cc=james@nurealm.net \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.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).