From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [RFC] ethtool: Support for driver private ioctl's Date: Thu, 5 Apr 2018 08:50:49 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org, Joao Pinto To: Jose Abreu , David Miller , Jakub Jelinek , Jeff Garzik , Tim Hockin , Eli Kupermann , Chris Leech , Scott Feldman , Ben Hutchings Return-path: Received: from mail-oi0-f42.google.com ([209.85.218.42]:43378 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751195AbeDEPux (ORCPT ); Thu, 5 Apr 2018 11:50:53 -0400 Received: by mail-oi0-f42.google.com with SMTP id u84-v6so22989315oie.10 for ; Thu, 05 Apr 2018 08:50:52 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 04/05/2018 03:47 AM, Jose Abreu wrote: > Hi All, > > I would like to know your opinion regarding adding support for > driver private ioctl's in ethtool. > > Background: Synopsys Ethernet IP's have a certain number of > features which can be reconfigured at runtime. Giving you two > examples: One of the most recent one is the safety features, > which can be enabled/disabled and forced at runtime. Another one > is a Flexible RX Parser which can route specific packets to > specific RX DMA channels. Given that these are features specific > to our IP's it would not be useful to add an uniform API for this > because the users would only be one or two drivers ... Parsing of packets and directing the matched packets to specific queues/channels can be done through ethtool rxnfc API, tc/cls_flower as well, so you should really check whether those APIs don't already allow you to do what you want. ethtool already supports a concept of private flags, not ioctl() though which allows you to toggle boolean values for instance (or technically up to how many bits a "flag" is used to represent) is that enough or do you need to turn on/off the feature as well as pass configuration parameters? > > This new feature would change the help usage for ethtool so that > each driver private option would be shown, and then each driver > specific file would have a structure with all the available > options. Finally, each driver would have to handle the private > IOCTL's. > > We already have this working locally and now I would like to know > your opinion about upstreaming this ... Do you think this can be > useful for anyone else? Or should we change direction to use, for > example, debugfs/configfs? In general, even if there is only one driver implementing a particular feature, the approach chosen is to come up with an API that is as generic as possible. Even if there is a single user of that API in tree, having something that was thought to be generic is better than allowing uncontrolled private ioctl() implementations. -- Florian