From: Jakub Kicinski <kuba@kernel.org>
To: Michal Kubecek <mkubecek@suse.cz>
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 12:18:25 -0700 [thread overview]
Message-ID: <20220316121825.6eb08c07@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20220316185232.ttsuvp4wbdxztned@lion.mk-sys.cz>
On Wed, 16 Mar 2022 19:52:32 +0100 Michal Kubecek wrote:
> > 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.
I was thinking let the driver specify which flags it is squatting on in
a mask in ethtool_ops, and then make sure the generic vs non-generic
flags are routed appropriately in the user space <> core communication.
We can also split the private vs generic on the ethtool_op level.
User space would have to jump thru extra hoops to figure the separation
out (maybe we can expose the "private mask" in get?)
I agree that the more we can separate the private and generic flags,
the better, that's just what I could come up with.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Michal Kubecek <mkubecek@suse.cz>
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 12:18:25 -0700 [thread overview]
Message-ID: <20220316121825.6eb08c07@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20220316185232.ttsuvp4wbdxztned@lion.mk-sys.cz>
On Wed, 16 Mar 2022 19:52:32 +0100 Michal Kubecek wrote:
> > 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.
I was thinking let the driver specify which flags it is squatting on in
a mask in ethtool_ops, and then make sure the generic vs non-generic
flags are routed appropriately in the user space <> core communication.
We can also split the private vs generic on the ethtool_op level.
User space would have to jump thru extra hoops to figure the separation
out (maybe we can expose the "private mask" in get?)
I agree that the more we can separate the private and generic flags,
the better, that's just what I could come up with.
next prev parent reply other threads:[~2022-03-16 19:18 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
2022-03-16 18:52 ` Michal Kubecek
2022-03-16 19:18 ` Jakub Kicinski [this message]
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=20220316121825.6eb08c07@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
--to=kuba@kernel.org \
--cc=aelior@marvell.com \
--cc=it+netdev@molgen.mpg.de \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=manishc@marvell.com \
--cc=mkubecek@suse.cz \
--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.