ethtool TODO list - additional info

ethtool TODO list - additional info

[Jorge Alberto Garcia]

Hi !

Some days ago, Jiri Pirko was talking about some next steps to
implement for ethtool.

 I haven't seen any follow up since ethtool's maintainer change. Can we have
additional details about these ?

- libethtool - API
- generic netlink
- sub commands syntax
- TODO/bugzilla


On Mon, Jul 4, 2016 at 9:24 AM, Jiri Pirko <jiri@resnulli.us> wrote:

>>> I was thinking of adding a TODO file to the repository, but it's really
>>> for the new maintainer to decide what to do.  So here's my list as a
>>> suggestion:
>>>
>>> * Add regression test coverage for all sub-commands with complex logic
>>>
>>> * Internationalise output and error messages
>>>
>>> * Build a libethtool that handles all the API quirks and fallbacks for
>>>   old kernel versions.  This might help people writing language
>>>   bindings or other utilities that use the ethtool API.
>>>
>>> * Provide a 'cleaned up' ethtool (under some other name) that has:
>>>   - More conventional sub-command syntax, i.e. no '-'/'--' prefix
>>>   - More consistent output formatting
>>
>>That seems like a reasonable start for a TODO list. I'll bet there
>>are a few people out there with other suggestions as well...?
>
> Before that, I would like to see ethtool migrate to use generic
> netlink. Then, the new tool would be needed anyway, should exist within
> iproute2 package and have similar command line syntax.
>
> I have some ideas about the gennetlink ethtool, have to find some time
> to implement some initial part of it.

Re: ethtool TODO list - additional info

[Jiri Pirko]

Tue, Jul 05, 2016 at 05:37:42PM CEST, jorge.garcia.gonzalez@gmail.com wrote:
>Hi !
>
>Some days ago, Jiri Pirko was talking about some next steps to
>implement for ethtool.
>
> I haven't seen any follow up since ethtool's maintainer change. Can we have
>additional details about these ?
>
>- libethtool - API
>- generic netlink

Yep, exactly, no reply. Apparently nobody really want to do any initiative
here, and I'm lacking time to do it :(



>- sub commands syntax
>- TODO/bugzilla
>
>
>On Mon, Jul 4, 2016 at 9:24 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>
>>>> I was thinking of adding a TODO file to the repository, but it's really
>>>> for the new maintainer to decide what to do.  So here's my list as a
>>>> suggestion:
>>>>
>>>> * Add regression test coverage for all sub-commands with complex logic
>>>>
>>>> * Internationalise output and error messages
>>>>
>>>> * Build a libethtool that handles all the API quirks and fallbacks for
>>>>   old kernel versions.  This might help people writing language
>>>>   bindings or other utilities that use the ethtool API.
>>>>
>>>> * Provide a 'cleaned up' ethtool (under some other name) that has:
>>>>   - More conventional sub-command syntax, i.e. no '-'/'--' prefix
>>>>   - More consistent output formatting
>>>
>>>That seems like a reasonable start for a TODO list. I'll bet there
>>>are a few people out there with other suggestions as well...?
>>
>> Before that, I would like to see ethtool migrate to use generic
>> netlink. Then, the new tool would be needed anyway, should exist within
>> iproute2 package and have similar command line syntax.
>>
>> I have some ideas about the gennetlink ethtool, have to find some time
>> to implement some initial part of it.

Re: ethtool TODO list - additional info

[Jorge Alberto Garcia]

On Tue, Jul 12, 2016 at 12:55 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Jul 05, 2016 at 05:37:42PM CEST, jorge.garcia.gonzalez@gmail.com wrote:
>>Hi !
>>
>>Some days ago, Jiri Pirko was talking about some next steps to
>>implement for ethtool.
>>
>> I haven't seen any follow up since ethtool's maintainer change. Can we have
>>additional details about these ?
>>
>>- libethtool - API
>>- generic netlink
>
> Yep, exactly, no reply. Apparently nobody really want to do any initiative
> here, and I'm lacking time to do it :(
>

That's fine,  I already got  a git repo, I'm trying to understand what
'use generic netlink' means.

This is a piece of what grep got me on iproute git repo (I'm still
trying to understand)
grep -i netlink -r iproute2/
iproute2/bridge/mdb.c:#include "libnetlink.h"
iproute2/bridge/vlan.c:#include "libnetlink.h"
...
..



>
>
>>- sub commands syntax
>>- TODO/bugzilla
>>
>>
>>On Mon, Jul 4, 2016 at 9:24 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>
>>>>> I was thinking of adding a TODO file to the repository, but it's really
>>>>> for the new maintainer to decide what to do.  So here's my list as a
>>>>> suggestion:
>>>>>
>>>>> * Add regression test coverage for all sub-commands with complex logic
>>>>>
>>>>> * Internationalise output and error messages
>>>>>
>>>>> * Build a libethtool that handles all the API quirks and fallbacks for
>>>>>   old kernel versions.  This might help people writing language
>>>>>   bindings or other utilities that use the ethtool API.
>>>>>
>>>>> * Provide a 'cleaned up' ethtool (under some other name) that has:
>>>>>   - More conventional sub-command syntax, i.e. no '-'/'--' prefix
>>>>>   - More consistent output formatting
>>>>
>>>>That seems like a reasonable start for a TODO list. I'll bet there
>>>>are a few people out there with other suggestions as well...?
>>>
>>> Before that, I would like to see ethtool migrate to use generic
>>> netlink. Then, the new tool would be needed anyway, should exist within
>>> iproute2 package and have similar command line syntax.
>>>
>>> I have some ideas about the gennetlink ethtool, have to find some time
>>> to implement some initial part of it.

Re: ethtool TODO list - additional info

[John W. Linville]

On Tue, Jul 12, 2016 at 01:04:52PM -0500, Jorge Alberto Garcia wrote:
> On Tue, Jul 12, 2016 at 12:55 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> > Tue, Jul 05, 2016 at 05:37:42PM CEST, jorge.garcia.gonzalez@gmail.com wrote:
> >>Hi !
> >>
> >>Some days ago, Jiri Pirko was talking about some next steps to
> >>implement for ethtool.
> >>
> >> I haven't seen any follow up since ethtool's maintainer change. Can we have
> >>additional details about these ?
> >>
> >>- libethtool - API
> >>- generic netlink
> >
> > Yep, exactly, no reply. Apparently nobody really want to do any initiative
> > here, and I'm lacking time to do it :(
> >
> 
> That's fine,  I already got  a git repo, I'm trying to understand what
> 'use generic netlink' means.
> 
> This is a piece of what grep got me on iproute git repo (I'm still
> trying to understand)
> grep -i netlink -r iproute2/
> iproute2/bridge/mdb.c:#include "libnetlink.h"
> iproute2/bridge/vlan.c:#include "libnetlink.h"
> ...
> ..

The general notion would be to replace the current ioctl-based
ethtool API with one that is based on netlink, like many of the other
networking APIs. I'm fine with the general idea of that, but so far
I haven't heard a strong case for why it is necessary. It certainly
doesn't seem urgent to me -- if someone disagrees, then please explain!

John

> >
> >
> >>- sub commands syntax
> >>- TODO/bugzilla
> >>
> >>
> >>On Mon, Jul 4, 2016 at 9:24 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >>>>> I was thinking of adding a TODO file to the repository, but it's really
> >>>>> for the new maintainer to decide what to do.  So here's my list as a
> >>>>> suggestion:
> >>>>>
> >>>>> * Add regression test coverage for all sub-commands with complex logic
> >>>>>
> >>>>> * Internationalise output and error messages
> >>>>>
> >>>>> * Build a libethtool that handles all the API quirks and fallbacks for
> >>>>>   old kernel versions.  This might help people writing language
> >>>>>   bindings or other utilities that use the ethtool API.
> >>>>>
> >>>>> * Provide a 'cleaned up' ethtool (under some other name) that has:
> >>>>>   - More conventional sub-command syntax, i.e. no '-'/'--' prefix
> >>>>>   - More consistent output formatting
> >>>>
> >>>>That seems like a reasonable start for a TODO list. I'll bet there
> >>>>are a few people out there with other suggestions as well...?
> >>>
> >>> Before that, I would like to see ethtool migrate to use generic
> >>> netlink. Then, the new tool would be needed anyway, should exist within
> >>> iproute2 package and have similar command line syntax.
> >>>
> >>> I have some ideas about the gennetlink ethtool, have to find some time
> >>> to implement some initial part of it.
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: ethtool TODO list - additional info

[John Fastabend]

On 16-07-12 11:12 AM, John W. Linville wrote:
> On Tue, Jul 12, 2016 at 01:04:52PM -0500, Jorge Alberto Garcia wrote:
>> On Tue, Jul 12, 2016 at 12:55 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Tue, Jul 05, 2016 at 05:37:42PM CEST, jorge.garcia.gonzalez@gmail.com wrote:
>>>> Hi !
>>>>
>>>> Some days ago, Jiri Pirko was talking about some next steps to
>>>> implement for ethtool.
>>>>
>>>> I haven't seen any follow up since ethtool's maintainer change. Can we have
>>>> additional details about these ?
>>>>
>>>> - libethtool - API
>>>> - generic netlink
>>>
>>> Yep, exactly, no reply. Apparently nobody really want to do any initiative
>>> here, and I'm lacking time to do it :(
>>>
>>
>> That's fine,  I already got  a git repo, I'm trying to understand what
>> 'use generic netlink' means.
>>
>> This is a piece of what grep got me on iproute git repo (I'm still
>> trying to understand)
>> grep -i netlink -r iproute2/
>> iproute2/bridge/mdb.c:#include "libnetlink.h"
>> iproute2/bridge/vlan.c:#include "libnetlink.h"
>> ...
>> ..
> 
> The general notion would be to replace the current ioctl-based
> ethtool API with one that is based on netlink, like many of the other
> networking APIs. I'm fine with the general idea of that, but so far
> I haven't heard a strong case for why it is necessary. It certainly
> doesn't seem urgent to me -- if someone disagrees, then please explain!
> 

And probably obvious but you can't remove the ioctl based ethtool
interface because we have a lot of software using it so you will have
to maintain both in parallel if there is a netlink equivalent.

Also most the stuff in ethtool tends to be things you set once at
init time or for debugging so the benefit of notifiers and such are
minimal.

Sure if I was doing it from scratch netlink would be better and there
are probably parts of it that are worth converting over where notifier
hooks and standardizing would be beneficial. I think Roopa for example
was coming up with some more general statistics mechanism.

My $.02 anyways.

JohnF

Re: ethtool TODO list - additional info

[David Miller]

From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 12 Jul 2016 14:12:52 -0400

> I haven't heard a strong case for why it is necessary.

Stats on large scale setups/systems is problematic and ethtool
is a part of that problem.

Extensibility in general suffers because of the ioctl() interface as
well.

For getting ethtool settings or stats, we have no clean filtering
mechanism.

I could go on and on...

I think before any new features are added to ethtool, we move over to
the netlink based interface and lock the existing ioctl() API in stone.

Re: ethtool TODO list - additional info

[John W. Linville]

On Tue, Jul 12, 2016 at 11:34:06AM -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Tue, 12 Jul 2016 14:12:52 -0400
> 
> > I haven't heard a strong case for why it is necessary.
> 
> Stats on large scale setups/systems is problematic and ethtool
> is a part of that problem.
> 
> Extensibility in general suffers because of the ioctl() interface as
> well.
> 
> For getting ethtool settings or stats, we have no clean filtering
> mechanism.
> 
> I could go on and on...
> 
> I think before any new features are added to ethtool, we move over to
> the netlink based interface and lock the existing ioctl() API in stone.

OK, then I'll start looking at this. Thanks for providing some clarity!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.