netdev - Re: ixgbe: How to do this without a module parameter?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k0i0bz2a.fsf@toke.dk>
Date:   Mon, 25 Oct 2021 22:59:41 +0200
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Robert Schlabbach <Robert.Schlabbach@....net>,
        netdev@...r.kernel.org
Subject: Re: ixgbe: How to do this without a module parameter?

Robert Schlabbach <Robert.Schlabbach@....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