All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Kubecek <mkubecek@suse.cz>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Manish Chopra <manishc@marvell.com>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	Ariel Elior <aelior@marvell.com>,
	Sudarsana Reddy Kalluru <skalluru@marvell.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"it+netdev@molgen.mpg.de" <it+netdev@molgen.mpg.de>
Subject: Re: [EXT] Re: bnx2x: ppc64le: Unable to set message level greater than 0x7fff
Date: Wed, 16 Mar 2022 19:52:32 +0100	[thread overview]
Message-ID: <20220316185232.ttsuvp4wbdxztned@lion.mk-sys.cz> (raw)
In-Reply-To: <20220316111754.5316bfb5@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Michal Kubecek <mkubecek@suse.cz>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
	Ariel Elior <aelior@marvell.com>,
	Manish Chopra <manishc@marvell.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"it+netdev@molgen.mpg.de" <it+netdev@molgen.mpg.de>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Sudarsana Reddy Kalluru <skalluru@marvell.com>
Subject: Re: [EXT] Re: bnx2x: ppc64le: Unable to set message level greater than 0x7fff
Date: Wed, 16 Mar 2022 19:52:32 +0100	[thread overview]
Message-ID: <20220316185232.ttsuvp4wbdxztned@lion.mk-sys.cz> (raw)
In-Reply-To: <20220316111754.5316bfb5@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-03-16 18:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 21:58 bnx2x: ppc64le: Unable to set message level greater than 0x7fff Paul Menzel
2022-03-16  1:35 ` Jakub Kicinski
2022-03-16  1:35   ` Jakub Kicinski
2022-03-16  5:16   ` Paul Menzel
2022-03-16  5:16     ` Paul Menzel
2022-03-16  5:33     ` Paul Menzel
2022-03-16  5:33       ` Paul Menzel
2022-03-16 11:49       ` [EXT] " Manish Chopra
2022-03-16 11:49         ` Manish Chopra
2022-03-16 18:17         ` Jakub Kicinski
2022-03-16 18:17           ` Jakub Kicinski
2022-03-16 18:52           ` Michal Kubecek [this message]
2022-03-16 18:52             ` Michal Kubecek
2022-03-16 19:18             ` Jakub Kicinski
2022-03-16 19:18               ` Jakub Kicinski

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=20220316185232.ttsuvp4wbdxztned@lion.mk-sys.cz \
    --to=mkubecek@suse.cz \
    --cc=aelior@marvell.com \
    --cc=it+netdev@molgen.mpg.de \
    --cc=kuba@kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=manishc@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=skalluru@marvell.com \
    /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.