[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YXiaG1q6Uw1xUsJx@lunn.ch>
Date: Wed, 27 Oct 2021 02:15:23 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Robert Schlabbach <Robert.Schlabbach@....net>
Cc: Toke Høiland-Jørgensen <toke@...hat.com>,
netdev@...r.kernel.org
Subject: Re: Re: ixgbe: How to do this without a module parameter?
On Wed, Oct 27, 2021 at 01:50:52AM +0200, Robert Schlabbach wrote:
> "Andrew Lunn" <andrew@...n.ch> wrote:
> > > 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...
> >
> > Something like this has been talked about before, but nobody ever
> > spent the time to do it. ethtool has all the needed strings, so it
> > should not be too hard to actually do for link modes.
>
> It appears somebody already did, because I found that my Debian 11.1
> server (with kernel version 5.14) actually takes this command:
>
> $ ethtool -s eno3 advertise 2500baseT/Full on 5000baseT/Full on
>
> The parsing seems to be implemented in the kernel, because when I copy
> the binary over to my Ubuntu machine (with kernel version 4.15), any
> attempt to specify a link mode name only yields:
Actually, it might not be. A kernel that old might not have netlink
ethtool, just the old ioctl interface. It could be the command line
parsing is dependent on which API is used to the kernel.
ethtool --debug 255 eno3
will show you the netlink messages going back and forth.
Andrew
Powered by blists - more mailing lists