Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3393501imj; Tue, 19 Feb 2019 02:45:39 -0800 (PST) X-Google-Smtp-Source: AHgI3IZCpSRfKRndn3ixuq8CrLoaIdqJNANJ9ili+wrR9fKLxnBUaFAPhBt8vLs5CDG29p9n1Ogm X-Received: by 2002:a63:e84c:: with SMTP id a12mr27007205pgk.241.1550573139229; Tue, 19 Feb 2019 02:45:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550573139; cv=none; d=google.com; s=arc-20160816; b=SYvcb9Q7N0bUzQKDWD6flV4O1cmn5/BUUoVQ9iX/tIucoerVpkIPcaOVi/MKjlsEZc TRY5PfLAOtw6YA6MLzmq98+DLqBY/Xx3xcsAyTNBSO0+w8OseTS1LMep/zIBpAUZNLBZ gzUI6/14ixmFGMlLauCDSBVN8sbarCSgE76o43PovIKErcPNnzQUUaQHTJZEseAkPeKb NjXLnXfB1IcbvMwau4CSOBWaZ8mKDycY0mQZP9PQ/3pko9omOeoC+e8c1pLA9NSRgh+0 QeRg13JDxVJucQCPMPEWleZliu2LFTqoqoa8oTrKOxwjP3GA6pDg35TAKqWFCFZMUSO8 s3TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=rtDgF/4pO6bgn4+W400+2ihpz/KXZL91ULnd1KBI6iI=; b=BI+y7ixEwSWJBi7Kz6tYJ0kM8Tc0e5qoiF31REv+0IUo4Y/z2cQhf9YaF4hUB8IKcn wc2ThObLkg8W7TO4VGDEs78etxaoXWtifBTRjU69yzV5nr9H4TkcLbjGz9JuTwkIeIJO 4SD0Y9UkQ29wf+lOP6DrUjHbV+829xL2O+kj71omisuxyndvGmt2nFTW6wM2HpGVImkJ XDJiuXTT9Yhz/MME2nffMwUZjeRGdiqdJFmsxvbbyB51zNoIip+1Ij4aAxbIl8ybyAe6 b4LIm4MXYkvQjVzjalBl2GTlN1J0vdSTEoNpp+UTuJkNFVUEj1wXgvfi8ihA5g7JI2vB ey7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@resnulli-us.20150623.gappssmtp.com header.s=20150623 header.b=D+mHtAkW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ck6si19457251plb.298.2019.02.19.02.45.24; Tue, 19 Feb 2019 02:45:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@resnulli-us.20150623.gappssmtp.com header.s=20150623 header.b=D+mHtAkW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728355AbfBSKoq (ORCPT + 99 others); Tue, 19 Feb 2019 05:44:46 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:52342 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726289AbfBSKoq (ORCPT ); Tue, 19 Feb 2019 05:44:46 -0500 Received: by mail-wm1-f66.google.com with SMTP id m1so2021662wml.2 for ; Tue, 19 Feb 2019 02:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rtDgF/4pO6bgn4+W400+2ihpz/KXZL91ULnd1KBI6iI=; b=D+mHtAkWeWimOwZaeIKQGtldp21MpfENNpNI+syyktxqV7y7HRC9Kv5yfghZS9SHFh 3/deYtRPeSxDAN6Zij2Up5zyfG74eHM4FFW9QWXQIof3uf3G3IOhmr8Zq1fjL3aZSQKW 90eaAEI1os4HcXqtGCkxwCcEcFm13orXOhfuiRXkX5Z+xITYRLTQ2p9uEtX0vlqouf+E NnhRKBP8J67UcMyta8uFpgwtmMqLw2uC+/VeGNm45Jr4RbjY4SoXRepMtlNiyHxCpSYF xRfD+AWNfRkEhWj9caUo2oTSUm629EqzzF31nljeYFi9psz8d5qwEYXEO/ybW2iVl0QO TOyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rtDgF/4pO6bgn4+W400+2ihpz/KXZL91ULnd1KBI6iI=; b=ptVkKOLg3uk9pem/ExZotBRRIf+HflVVtb2OUgV8xIIKPezjAE/tJfhBlpW/um9I9c LCTbQ0TR/Ft0apXoNtd0a3RAAvTgHeLVER1rz9iSISN9hCFFN2DDJJrJ++AKkZbeKAKr BHwhHVi3xGhELji002pFvAfvyxB3kjHvOQowIOu/13pRZTIksbmH8zzRovbrYSKkHz8k 0hbibXsuMGujM6/nTvPSDWr5z53YWAyHLugz/KF5uT/4ZD4x7fk7IAoRQf6nVv4RC8zb lXrF/6zS/hW4qyNunaw9JGLI+5vMvWXjYz53DRk4rzdfcVNm+TnnTPaxgBNXybTbkVFk C7wg== X-Gm-Message-State: AHQUAuYd86+zOrTWJzX0Hy4/8mFqtXEHg8hOJRJKYj+HPI/u8qNMT8Li +q42JmNU1xHlnA0mdYJsYIyRNw== X-Received: by 2002:a1c:cf41:: with SMTP id f62mr2466834wmg.1.1550573083524; Tue, 19 Feb 2019 02:44:43 -0800 (PST) Received: from localhost (ip-213-220-234-21.net.upcbroadband.cz. [213.220.234.21]) by smtp.gmail.com with ESMTPSA id h17sm1251297wmb.29.2019.02.19.02.44.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Feb 2019 02:44:43 -0800 (PST) Date: Tue, 19 Feb 2019 11:35:08 +0100 From: Jiri Pirko To: Michal Kubecek Cc: netdev@vger.kernel.org, David Miller , Andrew Lunn , Jakub Kicinski , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH net-next v3 00/21] ethtool netlink interface, part 1 Message-ID: <20190219103508.GD3080@nanopsycho> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mon, Feb 18, 2019 at 07:21:24PM CET, mkubecek@suse.cz wrote: >Note: this is marked as RFC because it's rather late in the cycle; the plan >is to make a regular submission (with changes based on review) once >net-next reopens after the 5.1 merge window. The full (work in progress) >series, together with the (userspace) ethtool counterpart can be found at >https://github.com/mkubecek/ethnl > >This is first part of alternative userspace interface for ethtool. The aim >is to address some long known issues with the ioctl interface, mainly lack >of extensibility, raciness, limited error reporting and absence of >notifications. > >The interface uses generic netlink family "ethtool"; it provides multicast >group "monitor" which is used for notifications. Documentation for the >interface is in Documentation/networking/ethtool-netlink.txt > >Basic concepts: > >- the goal is to provide all features of ioctl interface but allow > easier future extensions; at some point, it should be possible to have > full ethtool functionality without using the ioctl interface I'm not sure it is a good idea to map the existing iface to netlink fully. There are things in ethtool which are not really unique for Ethernet. Those things should be put somewhere else. >- 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, allows passing only the attributes to be > changed; therefore we don't need a get-modify-set cycle (which is > inherently racy), userspace can simply say what it wants to change >- provide notifications to multicast group "monitor" like rtnetlink does, > i.e. in the form of messages close to replies to "get" requests >- allow dump requests to get some information about all network devices > providing it >- be less dependent on ethtool and kernel being in sync; allow e.g. saying > "ethtool -s eth0 advertise foo off" without ethtool knowing what "foo" > means; it's kernel's job to know what mode "xyz" is and if it exists and > is supported > >Main changes between RFC v2 and RFC v3: > >- do not allow building as a module (no netdev notifiers needed) >- drop some obsolete fields >- add permanent hw address, timestamping and private flags support >- rework bitset handling to get rid of variable length arrays >- notify monitor on device renames >- restructure GET_SETTINGS/SET_SETTINGS messages >- split too long patches and submit only first part of the series > >Main changes between RFC v1 and RFC v2: > >- support dumps for all "get" requests >- provide notifications for changes related to supported request types >- support getting string sets (both global and per device) >- support getting/setting device features >- get rid of family specific header, everything passed as attributes >- split netlink code into multiple files in net/ethtool/ directory > >ToDo / open questions: > >- some features provided by ethtool would rather belong to devlink (and > some are already superseded by devlink); however, only few drivers > provide devlink interface at the moment and as recent discussion on > flashing revealed, we cannot rely on devlink's presence Could you explain why please? > >- 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 > >- currently, all communication with drivers via ethtool_ops is done > under RTNL as this is what ioctl interface does and likely many > ethtool_ops handlers rely on that; if we are going to rework ethtool_ops > in the future ("phase two"), it would be nice to get rid of it > >- ethtool_ops should pass extack pointer to allow drivers more meaningful > error reporting; it's not clear, however, how to pass information about > offending attribute > >- notifications are sent whenever a change is done via netlink API or > ioctl API and for netdev features also whenever they are updated using > netdev_change_features(); it would be desirable to notify also about > link state and negotiation result (speed/duplex and partner link > modes) but it would be more tricky > >Michal Kubecek (21): > netlink: introduce nla_put_bitfield32() > ethtool: move to its own directory > ethtool: introduce ethtool netlink interface > ethtool: helper functions for netlink interface > ethtool: netlink bitset handling > ethtool: support for netlink notifications > ethtool: implement EVENT notifications > ethtool: generic handlers for GET requests > ethtool: move string arrays into common file > ethtool: provide string sets with GET_STRSET request > ethtool: provide driver/device information in GET_INFO request > ethtool: provide permanent hardware address in GET_INFO request > ethtool: provide timestamping information in GET_INFO request > ethtool: provide link mode names as a string set > ethtool: provide link settings and link modes in GET_SETTINGS request > ethtool: provide WoL information in GET_SETTINGS request > ethtool: provide message level in GET_SETTINGS request > ethtool: provide link state in GET_SETTINGS request > ethtool: provide device features in GET_SETTINGS request > ethtool: provide private flags in GET_SETTINGS request > ethtool: send netlink notifications about setting changes > > Documentation/networking/ethtool-netlink.txt | 441 +++++++++++++ > include/linux/ethtool_netlink.h | 17 + > include/linux/netdevice.h | 14 + > include/net/netlink.h | 15 + > include/uapi/linux/ethtool.h | 10 + > include/uapi/linux/ethtool_netlink.h | 265 ++++++++ > include/uapi/linux/net_tstamp.h | 13 + > net/Kconfig | 8 + > net/Makefile | 2 +- > net/core/Makefile | 2 +- > net/ethtool/Makefile | 7 + > net/ethtool/bitset.c | 572 +++++++++++++++++ > net/ethtool/bitset.h | 40 ++ > net/ethtool/common.c | 227 +++++++ > net/ethtool/common.h | 29 + > net/ethtool/info.c | 332 ++++++++++ > net/{core/ethtool.c => ethtool/ioctl.c} | 244 ++----- > net/ethtool/netlink.c | 634 +++++++++++++++++++ > net/ethtool/netlink.h | 252 ++++++++ > net/ethtool/settings.c | 559 ++++++++++++++++ > net/ethtool/strset.c | 461 ++++++++++++++ > 21 files changed, 3937 insertions(+), 207 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/ethtool/Makefile > create mode 100644 net/ethtool/bitset.c > create mode 100644 net/ethtool/bitset.h > create mode 100644 net/ethtool/common.c > create mode 100644 net/ethtool/common.h > create mode 100644 net/ethtool/info.c > rename net/{core/ethtool.c => ethtool/ioctl.c} (91%) > create mode 100644 net/ethtool/netlink.c > create mode 100644 net/ethtool/netlink.h > create mode 100644 net/ethtool/settings.c > create mode 100644 net/ethtool/strset.c > >-- >2.20.1 >