There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started.

The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).

Links:

Looking for hackers with the skills:

kernel networking netlink c

This project is part of:

Hack Week 16 Hack Week 17 Hack Week 18 Hack Week 19

Activity

  • 2 months ago: jiriwiesner left netlink interface for ethtool
  • almost 2 years ago: dsterba liked netlink interface for ethtool
  • almost 2 years ago: pvorel liked netlink interface for ethtool
  • over 2 years ago: a_faerber liked netlink interface for ethtool
  • over 2 years ago: jiriwiesner joined netlink interface for ethtool
  • over 2 years ago: jiriwiesner liked netlink interface for ethtool
  • almost 3 years ago: mkubecek added keyword "kernel" to netlink interface for ethtool
  • almost 3 years ago: mkubecek added keyword "networking" to netlink interface for ethtool
  • almost 3 years ago: mkubecek added keyword "netlink" to netlink interface for ethtool
  • almost 3 years ago: mkubecek added keyword "c" to netlink interface for ethtool
  • All Activity

    Comments

    • mkubecek
      over 2 years ago by mkubecek | Reply

      I played a bit already, here is a small demo.

    • mkubecek
      over 2 years ago by mkubecek | Reply

      End-of-hackweek status: disappointing, to be honest. Because of a series of P0/P1 bugs, not much time was left to work on the project. The plan was to have 8-10 most common subcommands implemented on both kernel and ethtool side, ready for an RFC submission, and maybe also some work on wireshark dissector. Reality is much less impressive:

      • kernel: basic infrastructure, GET_DRVINFO, GET_SETTINGS and half of SET_SETTINGS
      • ethtool: basic infrastructure, ethtool -i <dev>

      Current code can be found in mkubece/ethnl on Github and home:mkubecek:ethnl OBS project. Let's hope we can get to an RFC submission by the end of this week (I would like to have ethtool ( | -s | -i ) <dev> working on both sides for that).

    • mkubecek
      about 2 years ago by mkubecek | Reply

      Marked the project for Hackweek 17 but I won't actually have Hackweek 17 in the usual sense due to Netdev conference. Instead, the plan is to dedicate five days (probably five Fridays in near future) to the project.

      Current state: kernel supports GET_DRVINFO, {G,S}ET_SETTINGS and {G,S}ET_PARAMS, dumps for all supported requests and notifications for SETTINGS and PARAMS (DRVINFO is read only by nature so there shouldn't be anything to notify). All of these requests are also supported by ethtool; the code for dumps (use* as device name) and monitoring (use --monitor as first parameter) also exists but the parser needs a bit more work to be presentable.

    • mkubecek
      about 1 year ago by mkubecek | Reply

      Status update just before Hackweek 18.

      Kernel series is almost ready for upstream submission of first part. The main missing part is unified request header and unified processing of it. There may also be some minor issues found in v5 review. Submitting v6 is the primary goal for Hackween 18 but it should only take part of the week (the smaller the better).

      More work needs to be done on userspace ethtool utility which is lagging behind a bit:

      • without EVENT notifications (rejected by upstream), monitor will need "lazy load" of string sets
      • some commands will require rtnetlink or devlink; rethink the context structure and socket handling
      • monitor needs to also listen to and react to rtnetlink and devlink notifications
      • syntax extensions need to be documented in man page
      • new debugging options showing structure of sent/received messages
      • use the same parser to interpret bad attribute offset from extack error/warning messages

    • mkubecek
      5 months ago by mkubecek | Reply

      Status update before Hackweek 19

      After few more review rounds and rewrites, initial part of the kernel series was accepted to net-next tree and reached mainline as part of the 5.6 merge window (so that it's going to appear in v5.6-rc1. What is in mainline at the moment allows netlink based implementation of

      • ethtool <dev>
      • ethtool s <dev> ...
      • ethtool -P <dev> (using rtnetlink)

      and corresponding notifications.

      The userspace ethtool counterpart, however, will need a lot of work to make it ready for upstream submission. As it is highly desirable to have it in ethtool 5.6 release, this is going to be the primary focus at least for the first part of Hackweek 19.

    • mkubecek
      5 months ago by mkubecek | Reply

      Status update after Hackweek 19

      TL;DR: The primary goal was achieved (12 minutes before the end of the week add-emoji ).

      Summary of the Hackweek 19 progress:

      • abstractions for netlink socket and message buffer separated from struct nl_context
      • rework the code generating multiple messages from one set of parameters (for ethtool -s)
      • rework "char bitset" parser (for ethtool -s <dev> wol ...)
      • drop bitfield32 helpers and other code no longer used
      • compatibility with existing test suite (make check succeeds now)
      • split some too long patches
      • some bugs fixed
      • lot of style cleanups
      • more comments and better commit messages
      • cover letter
      • current work in progress tracked on github again

      The resulting series has been submitted to upstream.

    Similar Projects

    Upstreaming of mediatek helios board by mbrugger

    The only Mediatek "hacker" board available is f...


    Help with mainline support for the Mediatek chromebook (MT8173 based) by mbrugger

    Lately the necessary patches to get rudimentary...


    ethtool ops for netdevsim by mkubecek

    This can be seen as a subproject of [ethtool ne...


    openSUSE/SLE/Mainline U-boot for some not-yet-supported ARM64 boards by ldevulder

    The Khadas VIM (http://khadas.com/vim/) is an a...


    Support for DRM platform drivers by tdz

    This project could get us rid of the last fbdev...


    ethtool ops for netdevsim by mkubecek

    This can be seen as a subproject of [ethtool ne...


    Hammer an Envoy service mesh onto a SAP S4/HANA landscape and watch everything explode. by STorresi

    Although CNCF projects are almost exclusively r...


    make "predictable network interface names" more predictable by mkubecek

    Since the so-called "predictable names" for net...


    Give avahi some love by e_bischoff

    Avahi is (among others) a domain names auto-con...


    Integrate Firecracker (microVMs) with a Cloud Foundry app runtime scheduler by tassis

    Description

    [Firecracker](https://firecrac...


    make "predictable network interface names" more predictable by mkubecek

    Since the so-called "predictable names" for net...


    ethtool ops for netdevsim by mkubecek

    This can be seen as a subproject of [ethtool ne...


    dmidecode: no more open-coded printfs by jdelvare

    There's a long standing request to extend the o...


    Improving picotm by tdz

    Picotm is a system-level transaction manager. I...