All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Robert Schlabbach <Robert.Schlabbach@gmx.net>, netdev@vger.kernel.org
Subject: Re: ixgbe: How to do this without a module parameter?
Date: Mon, 25 Oct 2021 22:59:41 +0200	[thread overview]
Message-ID: <87k0i0bz2a.fsf@toke.dk> (raw)
In-Reply-To: <trinity-50d23c05-6cfa-484b-be21-5177fcb07b75-1635193435489@3c-app-gmx-bap58>

Robert Schlabbach <Robert.Schlabbach@gmx.net> writes:

> A while ago, Intel devs sneaked a hack into the ixgbe driver which disables
> NBASE-T support by default:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?id=a296d665eae1e8ec6445683bfb999c884058426a
>
> Only after a user complaint, Intel bothered to reveal their reason for this:
>
> https://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg12615.html
>
> But this comes at the expense of NBASE-T users, who are left wondering why their
> NIC (which Intel sells as supporting NBASE-T) only comes up with GbE links. To
> fix this, I submitted this patch:
>
> https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20211018/026326.html
>
> However, Intel devs pointed out to me that private module parameters would no
> longer be accepted. Indeed, after some search I found this in the archive:
>
> https://lore.kernel.org/netdev/20170324.144017.1545614773504954414.davem@davemloft.net/
>
> The reason given there is that a module parameter is the "worst user experience
> possible". But I think the absolutely worst user experience possible is having
> to figure out a complex script that:
>
> - compiles a list of all net devices provided by the ixgbe module
> - retrieves the supported link speeds and converts them to a hex mask
> - ORs the NBASE-T speeds into this hex mask
> - finally runs ethtool to set the hex mask of the speeds to advertise
>
> Even as a developer with 10 years experience with Linux, I would have to spend
> quite a while writing such a script, and then figuring out how to have it
> executed at the right time during startup. I suppose the vast majority of
> Linux admins would be overwhelmed with that.
>
> In contrast, explaining how to set the module parameter to control NBASE-T
> support is a two-liner, see my patch above where I added that to the ixgbe.rst
> module documentation. I think that's feasible for most Linux admins.
>
> So my question is: Can anyone come up with a solution allowing to control
> NBASE-T support in the ixgbe module in a way that's feasible for most Linux
> admins, that works without a module parameter?
>
> If not, could an exception be made for this patch to allow an extra parameter
> for the ixgbe module?
>
> Or does anyone have an even better idea?

If it can be set with ethtool already, and the issue is mostly the
user-friendliness of this interface, how about teaching ethtool a
symbolic parameter to do this for you? E.g. something equivalent to:

'ethtool --change eth0 advertise +nbase-t' ?

Personally I wouldn't mind having this (symbolic names) for all the
supported advertised modes; I also think it's a pain to have to go
lookup the bit values whenever I need to change this...

-Toke


  reply	other threads:[~2021-10-25 20:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 20:23 ixgbe: How to do this without a module parameter? Robert Schlabbach
2021-10-25 20:59 ` Toke Høiland-Jørgensen [this message]
2021-10-25 21:11   ` Andrew Lunn
2021-10-25 23:47     ` Robert Schlabbach
2021-10-26  0:32       ` Andrew Lunn
2021-10-26 23:50     ` Aw: " Robert Schlabbach
2021-10-27  0:15       ` Andrew Lunn
2021-10-27 19:12         ` Robert Schlabbach

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=87k0i0bz2a.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=Robert.Schlabbach@gmx.net \
    --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 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.