[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220316185232.ttsuvp4wbdxztned@lion.mk-sys.cz>
Date: Wed, 16 Mar 2022 19:52:32 +0100
From: Michal Kubecek <mkubecek@...e.cz>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Manish Chopra <manishc@...vell.com>,
Paul Menzel <pmenzel@...gen.mpg.de>,
Ariel Elior <aelior@...vell.com>,
Sudarsana Reddy Kalluru <skalluru@...vell.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"it+netdev@...gen.mpg.de" <it+netdev@...gen.mpg.de>
Subject: Re: [EXT] Re: bnx2x: ppc64le: Unable to set message level greater
than 0x7fff
On Wed, Mar 16, 2022 at 11:17:54AM -0700, Jakub Kicinski wrote:
> On Wed, 16 Mar 2022 11:49:39 +0000 Manish Chopra wrote:
> > As ethtool over netlink has some limitations of the size,
> > I believe you can configure ethtool with "--disable-netlink" and set those message levels fine
>
> Yup, IIUC it works for Paul on a 5.17 system, that system likely has
> old ethtool user space tool which uses ioctls instead of netlink.
>
> What makes the netlink path somewhat non-trivial is that there is
> an expectation that the communication can be based on names (strings)
> as well as bit positions. I think we'd need a complete parallel
> attribute to carry vendor specific bits :S
Yes, that would be a way to go. However, in such case I would prefer
separating these driver/device specific message flags completely rather
then letting drivers grab currently unused flags (as is the case here,
IIUC) as those are likely to collide with future global ones.
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists