Netdev Archive on
help / color / mirror / Atom feed
From: Eric Dumazet <>
To: Michal Kubecek <>
Cc: "Kevin(Yudong) Yang" <>,
	netdev <>,
	Neal Cardwell <>
Subject: Re: [PATCH ethtool,v2] ethtool: add support show/set-time-stamping
Date: Tue, 8 Sep 2020 07:35:58 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Sep 7, 2020 at 11:25 PM Michal Kubecek <> wrote:
> On Mon, Sep 07, 2020 at 06:56:20PM +0200, Eric Dumazet wrote:
> > On Mon, Sep 7, 2020 at 2:53 PM Michal Kubecek <> wrote:
> > >
> > > As I said in response to v1 patch, I don't like the idea of adding a new
> > > ioctl interface to ethool when we are working on replacing and
> > > deprecating the existing ones. Is there a strong reason why this feature
> > > shouldn't be implemented using netlink?
> >
> > I do not think this is a fair request.
> >
> > All known kernels support the ioctl(), none of them support netlink so far.
> Several years ago, exactly the same was true for bonding, bridge or vlan
> configuration: all known kernels supported ioctl() or sysfs interfaces
> for them, none supported netlink at that point. By your logic, the right
> course of action would have been using ioctl() and sysfs for iproute2
> support. Instead, rtnetlink interfaces were implemented and used by
> iproute2. I believe it was the right choice.

Sure, but netlink does not yet provide the needed functionality for
our use case.

netlink was a medium/long term plan, for the kernel side at least.
I would totally understand and support a new iocl() in the kernel being blocked.
(In fact I have blocked Kevin from adding a sysfs and advised to use
existing ioctl())

Here we are not changing the kernel, we let ethtool use existing ABI
and old kernels.

I think you are mixing your own long term plans with simply letting ethtool
to meet existing kernel functionality.

> > Are you working on the netlink interface, or are you requesting us to
> > implement it ?
> If it helps, I'm willing to write the kernel side.

Yes please, that would help, but will still require months of
deployments at Google scale.

Or both, if
> necessary, just to avoid adding another ioctl monument that would have
> to be kept and maintained for many years, maybe forever.

The kernel part is there, and lack of equivalent  netlink support
means we have to keep it for ten years at least.

> > The ioctl has been added years ago, and Kevin patch is reasonable enough.
> And there is a utility using the ioctl, as Andrew pointed out. Just like
> there were brctl and vconfig and ioctl they were using. The existence of
> those ioctl was not considered sufficient reason to use them when bridge
> and vlan support was added to iproute2. I don't believe today's
> situation with ethtool is different.

I suspect Richard Cochran wrote the 190 lines of code outside of
ethtool because it was easier to not have to convince the ethtool
maintainer at that time :)

We do not have hwstamp_ctl deployed at this very moment, and for us it
is simply much faster to deploy a new ethtool version than having to
get security teams
approval to install a new binary.

Honestly, if this was an option, we would not have even bothered
writing ethtool support.

Now, you want netlink support instead of ioctl(), that is a very
different scope and amount of work.


  reply	other threads:[~2020-09-08  5:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03 14:07 [PATCH ethtool,v2] ethtool: add support show/set-time-stamping Kevin(Yudong) Yang
2020-09-07 12:53 ` Michal Kubecek
2020-09-07 16:56   ` Eric Dumazet
2020-09-07 21:25     ` Michal Kubecek
2020-09-08  5:35       ` Eric Dumazet [this message]
2020-09-08 10:37         ` Michal Kubecek
2020-09-08 11:17           ` Eric Dumazet

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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).