netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [RFC PATCH 0/9] ethtool netlink interface (WiP)
Date: Mon, 11 Dec 2017 14:53:11 +0100 (CET)	[thread overview]
Message-ID: <cover.1513000306.git.mkubecek@suse.cz> (raw)

This is still work in progress and only a very small part of the ioctl
interface is reimplemented but I would like to get some comments before
the patchset becomes too big and changing things becomes too tedious.

The interface used for communication between ethtool and kernel is based on
ioctl() and suffers from many problems. The most pressing seems the be the
lack of extensibility. While some of the newer commands use structures
designed to allow future extensions (e.g. GFEATURES or TEST), most either
allow no extension at all (GPAUSEPARAM, GCOALESCE) or only limited set of
reserved fields (GDRVINFO, GEEE). Even most of those which support future
extensions limit the data types that can be used.

This series aims to provide an alternative interface based on netlink which
is what other network configuration utilities use. In particular, it uses
generic netlink (family "ethtool"). The goal is to provide an interface
which would be extensible, flexible and practical both for ethtool and for
other network configuration tools (e.g. wicked or systemd-networkd).

The interface is documented in Documentation/networking/ethtool-netlink.txt

I'll post RFC patch series for ethtool in a few days, it still needs some
more polishing.

Basic concepts:

- the interface is based on generic netlink (family name "ethtool")

- provide everything ioctl can do but allow easier future extensions

- inextensibility of ioctl interface resulted in way too many commands,
  many of them obsoleted by newer ones; reduce the number by  ignoring the
  obsolete commands and grouping some together

- for "set" type commands, netlink allows providing only the attributes to
  be changed; therefore we don't need a get-modify-set cycle, userspace can
  simply say what it wants to change and how

- be less dependent on ethtool and kernel being in sync; allow e.g. saying
  "ethtool -s eth0 advertise xyz off" without knowing what "xyz" means;
  it's kernel's job to know what mode "xyz" is and if it exists and is
  supported

Unresolved questions/tasks:

- allow dumps for "get" type requests, e.g. listing EEE settings for all
  interfaces in current netns

- find reasonable format for data transfers (e.g. eeprom dump or flash)

- while the netlink interface allows easy future extensions, ethtool_ops
  interface does not; some settings could be implemented using tunables and
  accessed via relevant netlink messages (as well as tunables) from
  userspace but in the long term, something better will be needed

- it would be nice if driver could provide useful error/warning messages to
  be passed to userspace via extended ACK; example: while testing, I found
  a driver which only allows values 0, 1, 3 and 10000 for certain parameter
  but the only way poor user can find out is either by trying all values or
  by checking driver source

Michal Kubecek (9):
  netlink: introduce nla_put_bitfield32()
  ethtool: introduce ethtool netlink interface
  ethtool: helper functions for netlink interface
  ethtool: netlink bitset handling
  ethtool: implement GET_DRVINFO message
  ethtool: implement GET_SETTINGS message
  ethtool: implement SET_SETTINGS message
  ethtool: implement GET_PARAMS message
  ethtool: implement SET_PARAMS message

 Documentation/networking/ethtool-netlink.txt |  466 ++++++
 include/linux/ethtool_netlink.h              |   12 +
 include/linux/netdevice.h                    |    2 +
 include/net/netlink.h                        |   15 +
 include/uapi/linux/ethtool.h                 |    3 +
 include/uapi/linux/ethtool_netlink.h         |  239 +++
 net/Kconfig                                  |    7 +
 net/core/Makefile                            |    3 +-
 net/core/ethtool.c                           |  150 +-
 net/core/ethtool_common.c                    |  158 ++
 net/core/ethtool_common.h                    |   19 +
 net/core/ethtool_netlink.c                   | 2323 ++++++++++++++++++++++++++
 12 files changed, 3260 insertions(+), 137 deletions(-)
 create mode 100644 Documentation/networking/ethtool-netlink.txt
 create mode 100644 include/linux/ethtool_netlink.h
 create mode 100644 include/uapi/linux/ethtool_netlink.h
 create mode 100644 net/core/ethtool_common.c
 create mode 100644 net/core/ethtool_common.h
 create mode 100644 net/core/ethtool_netlink.c

-- 
2.15.1

             reply	other threads:[~2017-12-11 13:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-11 13:53 Michal Kubecek [this message]
2017-12-11 13:53 ` [RFC PATCH 1/9] netlink: introduce nla_put_bitfield32() Michal Kubecek
2017-12-11 13:53 ` [RFC PATCH 2/9] ethtool: introduce ethtool netlink interface Michal Kubecek
2017-12-11 16:02   ` Jiri Pirko
2017-12-11 16:56     ` David Miller
2017-12-11 18:02       ` Jiri Pirko
2017-12-11 18:45         ` David Miller
2017-12-12 23:56           ` Michal Kubecek
2017-12-11 13:53 ` [RFC PATCH 3/9] ethtool: helper functions for " Michal Kubecek
2017-12-11 13:53 ` [RFC PATCH 4/9] ethtool: netlink bitset handling Michal Kubecek
2017-12-11 13:54 ` [RFC PATCH 5/9] ethtool: implement GET_DRVINFO message Michal Kubecek
2017-12-11 16:16   ` Jiri Pirko
2017-12-12 23:54     ` Michal Kubecek
2017-12-13  6:57       ` Jiri Pirko
2017-12-11 13:54 ` [RFC PATCH 6/9] ethtool: implement GET_SETTINGS message Michal Kubecek
2017-12-11 13:54 ` [RFC PATCH 7/9] ethtool: implement SET_SETTINGS message Michal Kubecek
2017-12-11 13:54 ` [RFC PATCH 8/9] ethtool: implement GET_PARAMS message Michal Kubecek
2017-12-11 13:54 ` [RFC PATCH 9/9] ethtool: implement SET_PARAMS message Michal Kubecek
2017-12-11 16:32 ` [RFC PATCH 0/9] ethtool netlink interface (WiP) Jiri Pirko
2017-12-11 17:01   ` David Miller
2017-12-11 17:59     ` Jiri Pirko
2017-12-11 19:03     ` Florian Fainelli
2017-12-12 15:32 ` Roopa Prabhu
2017-12-12 23:47   ` Jakub Kicinski
2017-12-14 21:07 ` John W. Linville
2017-12-18 19:39   ` 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=cover.1513000306.git.mkubecek@suse.cz \
    --to=mkubecek@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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).