Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752835AbdLLXry (ORCPT ); Tue, 12 Dec 2017 18:47:54 -0500 Received: from mx3.wp.pl ([212.77.101.10]:38962 "EHLO mx3.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752723AbdLLXrt (ORCPT ); Tue, 12 Dec 2017 18:47:49 -0500 Date: Tue, 12 Dec 2017 15:47:41 -0800 From: Jakub Kicinski To: Roopa Prabhu Cc: Michal Kubecek , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Jiri Pirko , David Miller Subject: Re: [RFC PATCH 0/9] ethtool netlink interface (WiP) Message-ID: <20171212154741.3110fb2b@cakuba.netronome.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-WP-MailID: af11ef98989626cf5c4c3f1e65b8ed05 X-WP-AV: skaner antywirusowy Poczty Wirtualnej Polski X-WP-SPAM: NO 000000A [cYMk] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1340 Lines: 29 On Tue, 12 Dec 2017 07:32:44 -0800, Roopa Prabhu wrote: > Thanks for working on this!. Agree with most comments already > discussed on this thread. > I would prefer if we fold ethtool netlink into devlink since there is > already an overlap. > many reasons: > - have just one driver api for device global and per port config > (devlink already provides that) > - some of the devlink commands like port split/unsplit can already be > applied per netdev (and since you bring up network interface managers, > we are looking at getting these in network managers for switch ports) > - if we keep them separate, we will soon see that drivers will need > handlers for both devlink and ethtool > - and the overlap is going to be confusing for both drivers and user-space +1 FWIW my gut feeling is that extending devlink-port makes more sense than creating another command. Although things like RSS tables don't feel very natural in port context. The other issue that springs to mind is that ethtool ops take RTNL lock today, and devlink doesn't. It would be cool if we could make ethtool not require RTNL lock (and drivers didn't have to drop locks half way through the .flash_device callback, sigh...) but OTOH that would make the driver conversion more brittle and potentially block the much needed netlink conversion... That's my $0.02 ;)