From: Michal Kubecek <mkubecek@suse.cz>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>,
Jiri Pirko <jiri@resnulli.us>,
davem@davemloft.net, netdev@vger.kernel.org,
oss-drivers@netronome.com, andrew@lunn.ch
Subject: Re: [PATCH net-next 3/3] nfp: devlink: allow flashing the device via devlink
Date: Thu, 21 Feb 2019 08:17:23 +0100 [thread overview]
Message-ID: <20190221071723.GL23151@unicorn.suse.cz> (raw)
In-Reply-To: <befeae18-f80e-6f2f-3e97-28629200cf92@gmail.com>
On Wed, Feb 20, 2019 at 06:59:05PM -0800, Florian Fainelli wrote:
> On 2/19/2019 4:49 PM, Jakub Kicinski wrote:
> > On Tue, 19 Feb 2019 10:19:42 +0100, Jiri Pirko wrote:
> >> Fri, Feb 15, 2019 at 04:44:29PM CET, jakub.kicinski@netronome.com wrote:
> >>> On Fri, 15 Feb 2019 11:15:14 +0100, Jiri Pirko wrote:
> >>>>> static const struct ethtool_ops nfp_net_ethtool_ops = {
> >>>>
> >>>> Why don't you use the compat fallback? I think you should.
> >>>
> >>> You and Michal both asked the same so let me answer the first to ask :)
> >>> - if devlink is built as a module the fallback is not reachable.
> >>
> >> So the fallback is not really good as you can't use it for real drivers
> >> anyway. Odd. Maybe we should compile devlink in without possibility to
> >> have it as module.
> >
> > Ack, I'll make devlink a bool.
>
> Meh how about those poor and memory constrained embedded systems?
> Ideally ethtool should/could have been modular as well, but that ship
> has now sailed.
I would certainly like to make the ioctl interface optional once we
reach the end of "phase one", i.e. make ioctl-less ethtool possible.
Looking at the code, I don't see an obvious reason why it couldn't be
modular.
There seem to be only few functions in net/core/ethtool.c which are
called from outside and all seem to be simple helpers not really tied to
the rest of the code, except for netdev_rss_key variable (needed for
/proc/sys/net/core/netdev_rss_key). Some of them could even be inline.
We could always put these into some net/ethtool/stub.c (ethtool-stub.c)
and build unconditionally.
So if keeping the option to have devlink (and ethtool) as a module is
really desirable, I believe it can be done even now (unless I missed
something important).
> We have had similar issues with PHYLIB before where we wanted
> net/core/ethtool.c to be able to call into generic PHYLIB functions to
> obtain PHY statistics, an inline helper that de-references the PHY
> device's driver function pointers solved that (look for
> phy_ethtool_get_{strings,sset,stats}) while letting PHYLIB remain modular.
There is also something similar in netfilter - nf_ct_hook, nfnl_ct_hook
or nf_ipv6_ops.
> devlink_compat_flash_update() is a bit big to be inlined, but why not?
Most of it seems to be the lookup which I'm planning to factor out as
a separate helper. But that would also need to be available to external
code, of course.
Michal
next prev parent reply other threads:[~2019-02-21 7:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 21:40 [PATCH net-next 0/3] devlink: add the ability to update device flash Jakub Kicinski
2019-02-14 21:40 ` [PATCH net-next 1/3] devlink: add flash update command Jakub Kicinski
2019-02-15 10:10 ` Jiri Pirko
2019-02-14 21:40 ` [PATCH net-next 2/3] ethtool: add compat for flash update Jakub Kicinski
2019-02-15 8:53 ` Michal Kubecek
2019-02-15 10:17 ` Jiri Pirko
2019-02-15 15:51 ` Jakub Kicinski
2019-02-15 10:12 ` Jiri Pirko
2019-02-14 21:40 ` [PATCH net-next 3/3] nfp: devlink: allow flashing the device via devlink Jakub Kicinski
2019-02-15 10:15 ` Jiri Pirko
2019-02-15 15:44 ` Jakub Kicinski
2019-02-19 9:19 ` Jiri Pirko
2019-02-20 0:49 ` Jakub Kicinski
2019-02-20 8:37 ` Jiri Pirko
2019-02-21 2:59 ` Florian Fainelli
2019-02-21 3:20 ` Jakub Kicinski
2019-02-21 7:00 ` Jiri Pirko
2019-02-21 7:17 ` Michal Kubecek [this message]
2019-02-15 10:26 ` Michal Kubecek
2019-02-17 23:28 ` [PATCH net-next 0/3] devlink: add the ability to update device flash David Miller
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=20190221071723.GL23151@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jakub.kicinski@netronome.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).