netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Michael Chan <michael.chan@broadcom.com>
Cc: Vasundhara Volam <vasundhara-v.volam@broadcom.com>,
	David Miller <davem@davemloft.net>,
	Jiri Pirko <jiri@mellanox.com>, Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next RFC 7/7] bnxt_en: Add bnxt_en initial port params table and register it
Date: Wed, 5 Dec 2018 16:42:03 -0800	[thread overview]
Message-ID: <20181205164203.230c44e8@cakuba.netronome.com> (raw)
In-Reply-To: <CACKFLikR5G1vca31hyjJ3uZbV1Zq-86a9=qXeUaO1gqosDg9GQ@mail.gmail.com>

On Wed, 5 Dec 2018 16:01:08 -0800, Michael Chan wrote:
> On Wed, Dec 5, 2018 at 3:33 PM Jakub Kicinski
> <jakub.kicinski@netronome.com> wrote:
> >
> > On Wed,  5 Dec 2018 11:27:00 +0530, Vasundhara Volam wrote:  
> > > Register devlink_port with devlink and create initial port params
> > > table for bnxt_en. The table consists of a generic parameter:
> > >
> > > wake-on-lan: Enables Wake on Lan for this port when magic packet
> > > is received with this port's MAC address using ACPI pattern.
> > > If enabled, the controller asserts a wake pin upon reception of
> > > WoL packet.  ACPI (Advanced Configuration and Power Interface) is
> > > an industry specification for the efficient handling of power
> > > consumption in desktop and mobile computers.
> > >
> > > Cc: Michael Chan <michael.chan@broadcom.com>
> > > Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>  
> >
> > Why do we need a WoL as a devlink parameter (rather than ethtool -s)?  
> 
> I believe ethtool -s for WoL is a non-persistent setting, meaning that
> if you power cycle the system, the WoL setting will go back to
> default.
> 
> devlink on the other hand is a permanent setting.  ethtool should
> initially report the default WoL setting and it can then be changed
> (in a non permanent way) using ethtool -s.

All network configuration settings in Linux are non-persistent AFAIK.
That's why network configuration daemons exist:

https://wiki.debian.org/WakeOnLan

Perhaps the objective to move more of the network configuration into the
firmware?  That'd be a bleak scenario, so probably not..

My understanding was the persistent devlink settings are for things
which have to be set at device init time.  Like say PCI endpoint
configuration.  FW loading configuration.

Besides, the parameter you add is just true/false, when ethtool has
multiple options.

It feels to me like we moved from ioctls to Netlink, and now even
before ethtool was converted to Netlink we may move to unstructured
strings.  That's not a step forward, if you ask me.

  reply	other threads:[~2018-12-06  0:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05  5:56 [PATCH net-next RFC 0/7] Add configuration parameters support for devlink_port Vasundhara Volam
2018-12-05  5:56 ` [PATCH net-next RFC 1/7] devlink: Add devlink_param for port register and unregister Vasundhara Volam
2018-12-05 11:47   ` Jiri Pirko
2018-12-06  6:02     ` Vasundhara Volam
2018-12-06  7:06       ` Jiri Pirko
2018-12-06  7:26         ` Vasundhara Volam
2018-12-10  9:21     ` Vasundhara Volam
2018-12-10 11:29       ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 2/7] devlink: Add port param get command Vasundhara Volam
2018-12-05 11:51   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 3/7] devlink: Add port param set command Vasundhara Volam
2018-12-05 12:13   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 4/7] devlink: Add support for get/set driverinit value for devlink_port Vasundhara Volam
2018-12-05 12:59   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 5/7] devlink: Add devlink notifications support for port params Vasundhara Volam
2018-12-05 13:02   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 6/7] devlink: Add a boolean generic port parameter Vasundhara Volam
2018-12-05 13:04   ` Jiri Pirko
2018-12-05  5:57 ` [PATCH net-next RFC 7/7] bnxt_en: Add bnxt_en initial port params table and register it Vasundhara Volam
2018-12-05 13:05   ` Jiri Pirko
2018-12-05 23:33   ` Jakub Kicinski
2018-12-06  0:01     ` Michael Chan
2018-12-06  0:42       ` Jakub Kicinski [this message]
2018-12-06  1:18         ` Michael Chan
2018-12-06  6:00           ` Jakub Kicinski
2018-12-06  6:41             ` Michael Chan
2018-12-06  7:11               ` Jakub Kicinski
2018-12-06  8:57                 ` Michael Chan
2018-12-06  9:03                   ` Jiri Pirko
2018-12-06 10:31                     ` Vasundhara Volam
2018-12-06 11:11                       ` Jiri Pirko
2018-12-06 10:36                   ` Jakub Kicinski
2018-12-06 11:00                     ` Michael Chan

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=20181205164203.230c44e8@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=davem@davemloft.net \
    --cc=jiri@mellanox.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=vasundhara-v.volam@broadcom.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).