netdev - Re: the future of ethtool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1289852326.2586.32.camel@bwh-desktop>
Date:	Mon, 15 Nov 2010 20:18:46 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	NetDev <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>
Subject: Re: the future of ethtool

On Mon, 2010-11-15 at 14:41 -0500, Jeff Garzik wrote:
> Thanks for accepting ethtool maintainership.
> 
> There are two key unresolved issues with ethtool that are worth noting 
> to the next maintainer.  Both of these come from years of user and 
> customer complaints.
> 
> 1) ethtool command line interface.
> 
> For 1,001 minor reasons of user taste and expectation, people tend to 
> complain about the command line interface.  Due to script usage it is 
> set in stone, and has been since before my tenure.  But users 
> continually request something more flexible, often, in particular, 
> wanting to set multiple settings in one execution, or wanting to apply 
> the same setting to multiple interface in one execution.
> 
> Obviously one can script this, but, it is probably the #1 user request.

Thinking further along those lines, it would be useful to have ethtool
API bindings for Perl/Python/whatever, though those belong outside of
the current ethtool package.  I tried doing that for use in my own
scripts and it looks reasonably practical, though I'm not volunteering
to maintain such bindings.

> My thought was to create "nictool", a new tool with more flexible 
> command line interface, using the same old ethtool ioctls currently in 
> use today.  ('nictool' also solves a minor naming complaint from 
> wireless and other people, who use ethtool on non-ethernet network 
> interfaces)

I agree, some of the ethtool operations are very Ethernet-specific but
enough of them are applicable to other media that this makes sense.

I've recently been looking at FreeBSD where the sort of configuration we
do through ethtool is invoked through ifconfig, but then ifconfig is
effectively deprecated on Linux...

> 2) multiple settings and the ethtool kernel interface
> 
> Another common complaint is related to multiple settings, and associated 
> hardware NIC resets.
> 
> Many ethtool driver implementations look like this:
> 
> 	ethtool_op_do_something()
> 		stop RX/TX
> 		apply settings
> 		perform full NIC reset, consuming much time
> 		start RX/TX
> 
> The problem arises when the user wishes to change multiple hardware 
> attributes at the same time.  A user wishing to change 4 attributes 
> could wind up with 4 ethtool(1) invocations, with 4 accompanying 
> hardware NIC resets.  Time consuming, inefficient, and unnecessary.

Right.  In fact the begin() and complete() operations look like they
were meant to support this sort of optimisation.  Is that the case?

Ben.

> Obviously the world has not ended without these changes, but these items 
> do cause continued complaints from users, and we're here to be 
> responsive to users presumably ;-)


-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html